Где хранятся свойства в IFC

Свойства и количественные показатели в IFC группируются в наборы. За это отвечает второй ключевой потомок корня IfcRoot – класс IfcPropertyDefinition.

Он делится на две ветки:

🔹 Ветка IfcPropertySetDefinition содержит описания наборов свойств и количественных показателей, присваиваемые элементам модели.
Некоторые свойства (и их наборы) закреплены стандартом IFC и имеют строгие имена и типы данных. Стандартные наборы свойств имеют префикс Pset_. Наборы количественных показателей начинаются с Qto_ .

🔹 Ветка IfcPropertyTemplateDefinition позволяет создать «шаблонные» наборы и свойства с указанием их имён, но без указания значений. Такие шаблоны свойств и наборов наполняют библиотеку проекта (IfcProjectLibrary). Причем библиотечные шаблоны и примененные наборы свойств связываются между собой с помощью отношений.

✈️ Аналог таких шаблонов - файл общих параметров в Ревите, который по сути является библиотекой свойств для проекта. Но в Ревите нельзя создать «шаблонных» наборов, которые бы позволяли сгруппировать свойства в проекте. Группы параметров там строго фиксированы, что зачастую вызывает ряд неудобств для пользователей.

✈️ В IFC таких ограничений нет. И группировать пользовательские свойства можно как угодно в любом количестве с любыми наименованиями.

#База
📢@ifc_ru

Вебинар «nanoCAD BIM Конструкции – возможности импорта и экспорта IFC»

- Возможности импорта IFC-моделей для работы с опорными моделями
- Экспорт IFC
- Настройка маппинга параметров
- Профили экспорта IFC

🧩 СМОТРИМ

Топоматик Robur добавил возможность экспорта модели по схеме IFC 4х3 и IFC4.

🌐 Первый пошел.

📢 @ifc_ru
👥 @ifc_club

Связи в IFC

Структура IFC - это не про свалку геометрии с параметрами. Как мы уже отмечали ранее, в основе лежит строгая иерархия наследуемых классов, связанных посредством отношений (или связей) и ссылок.

Отношения в IFC выделены как отдельные классы (объективированы). Верхнеуровневых связей, относящихся непосредственно к родителю IfcRelationship, всего 6. Из них 5 являются родительскими абстрактными классами для множества связей-потомков.

Каждое отношение может связывать объекты по следующим принципам:
🔹 "один к одному" - связь одного объекта с другим;
🔹 "один ко многим" - связь одного объекта с одним и более объектами.
Многого ко многим в IFC нет.

🔍 Некоторые связи не включены в стандартизованные MVD (например, IFC4 Reference View), поэтому искать их в таких моделях нет смысла. Кроме того, часть имеющихся в стандарте IFC связей в принципе не формируется в САПР. Но это уже вопросы к ПО.

✈️ Зачем выделять связи как классы? Не проще ли упростить структуру модели и наполнять геометрию свойствами?

Обратимся к официальной странице стандарта:

Объективированные связи являются предпочтительным способом обработки отношений между объектами. Это позволяет сохранить специфические свойства связи непосредственно в отношениях и в дальнейшем управлять поведением отношений.

#База
@ifc_ru

Что дают связи в IFC

🔹Может ли модель быть без связей между элементами? - Вполне.
🔹Поможет ли это в работе с данными в модели? - Вряд ли.

Рассмотрим основные назначения связей в IFC.

🔹 Связи обеспечивают структурную целостность модели, гарантируя, что данные, связанные между собой, соответствуют семантическим правилам. Контроль целостности в свою очередь повышает достоверность информации в модели. Например, благодаря связям мы можем убедиться, что дверь действительно принадлежит стене, а не болтается сама по себе.

🔹 Связи позволяют писать сложные запросы, включающие данные из нескольких сущностей. К примеру, для элемента "Помещения" вы можете написать запрос, выдающий информацию о связанных с ним конструкциях (с помощью связи IfcRelSpaceBoundary), ограничивающих это помещение, и проверить их пожарные характеристики.

🔹 Связи обеспечивают формирование геометрии. Так, именно благодаря IfcRelVoidsElement из геометрии стены (перекрытия или иного элемента) вырезается геометрия отверстий/проемов/ниш.
Т.е. изначально геометрия стены описывается без проемов, что позволяет получить у нее объем и площадь брутто, сократить число начальных полигонов, описать ее параметрически (например, осевой линией с выдавливанием).

🔹 Связи помогают избежать дублирования и избыточности данных. Например, свойства типа для элементов окна привязываются к каждому экземпляру окна при помощи отношений из набора IfcRelDefines.

🔹 Связи позволяют легко обновлять данные: меняя их в одном месте, эти изменения отразятся в связанных сущностях. Допустим, вы обновляете свойства типа о том же окне - все связанные с ним экземпляры окон будут также обновлены.

Это обычный, но важный функционал САПР, о котором мы уже не задумываемся.

В этом смысле добавление элементам свойств, чтобы каким-то образом обозначить связь с другим элементом или группой видится весьма сомнительным решением. К примеру, назначив помещениям "номер квартиры", при необходимости вам придется менять его в каждом помещении в составе квартиры.

#База
@ifc_ru

💣 XML-бомба, способная изменить всё!

НОСТРОЙ разместил предварительный перечень XML-документов, входящих в состав ИМ ОКС по ПП 614.

Разработка более 300 XML-схем планируется членами Комитета НОСТРОЙ, НОПРИЗ, членами рабочей группы по разработке XML-схем при Минстрое.

🔍 Что здесь важно:
Перечень содержит XML-документы, которые могут СУЩЕСТВЕННО повлиять на процесс цифровизации отрасли.

Например:
- спецификации оборудования и других элементов здания;
- экспликации помещений;
- ведомости объемов бетона;
- ведомости отделки помещений и фасадов;
- и так далее.

📄 То есть все табличные данные проектной документации также планируется перевести в XML-форму.

Что это дает?

🔹 Это позволит связать выгруженные спецификации с элементами модели. Реализуется это с помощью GUID элементов.

🔹 В отличие от PDF-чертежей это позволит не только просматривать, но и проверять ведомости вместе с моделью в IFC. То есть табличная часть 2D-документации обретёт цифровую форму.

🔍 Но самое главное, что для этого придется выгружать спецификации непосредственно из модели.
Ведь создавать XML-документы спецификаций "руками" - занятие не из легких.

Для реализации этих планов понадобится:
🔹в рамках ПО создать плагины для выгрузки этих XML из модели. При этом для корректной работы плагинов придется создавать корректные модели в стандартизованном виде;
🔹определить юридическую значимость для такого рода документов, так как на текущий момент они являются неотъемлемой частью чертежей.

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

P.S. Новость о данном перечне прошла еще неделю назад, но странно, что ни один BIM-паблик не обратил на это внимания.

@ifc_ru
@ifc_club

🔍Бесплатный IFC viewer, IDS-редактор и валидатор моделей

Компания Sortdesk выпустила бета-версию IFC-просмотрщика в браузере.

Преимущества:
✈️ Просмотрщик не требует установки и регистрации, всё в браузере;
✈️ Конфиденциальность прежде всего: ваши данные никогда не покидают ваш компьютер.

Также есть бесплатная возможность:
✈️ загрузить модель в облако. Нужна регистрация. Если зарегистрироваться сейчас, обещают увеличить облачную квоту до 250 МБ;
✈️ создать и отредактировать IDS-требования;
✈️ проверить модель на IDS-требования;
🔥 посмотреть прямо в модели, какие объекты соответствуют требованиям, а какие нет.

#IDS
@ifc_ru
@ifc_club

С какой стороны смотреть на LODы

Уровни геометрической проработки ЦИМ по СП 333.2020 отличаются от известных всем LODов, которые разрабатывал американский BIM Forum. И дело не только в обозначениях.

Проблема в том, что обе эти концепции имеют определенные сложности и противоречия, и они до сих пор не могут прижиться на практике.

✈️ Может быть, стоит рассматривать LODы с другой, технической, стороны вопроса?

✈️ Предпосылки к этому читайте В СТАТЬЕ.

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

🗓️ Среда, 3 июля, в 16-00 МСК

🔊 Тема: "Автоматическая экспертиза ЦИМ: мифы, реальность и перспективы"

Гость:
👤 Ольга Кутузова, продакт-менеджер направления NSR NormaCS Specification, ООО "Нанософт Разработка"

Поговорим о:
🛑разработках компании Нанософт в части автоматизации проверок моделей;
🛑принципах и особенностях создания цифровых требований к моделям;
🛑перспективах применения такого подхода.

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

👥 @IFC_ru
👥 @IFC_club

✈️ Запись эфира "BIM-среда" доступна на Youtube-канале 📹

✈️ Тема: Автоматическая экспертиза ЦИМ, мифы, реальность и перспективы
✈️ Спикер - Ольга Кутузова, продакт-менеджер направления NSR NormaCS Specification, ООО "Нанософт Разработка"

✈️ И напоследок статья Ольги:
- Через тернии к… автоматической экспертизе цифровой информационной модели.

@IFC_ru
@IFC_club

IDS на практике

Презентация buildingSMART о концепции IDS и его применении.

📹 https://www.youtube.com/watch?v=SaRtOFpW0zk

@ifc_ru

Объединяйте IFC-файлы в один!

IFC Suite собирает несколько файлов IFC в один благодаря функции «Merge IFC».

В процессе создания объединенного файла можно:
🔹управлять объединением участков (IfcSite) в один.
🔹 собирать "здания" (IfcBuilding) в одно.
🔹 соединять этажи по имени и по отметке либо оставлять их как есть.

В разработке еще несколько функций: разделение моделей, чистка, выгрузка IFC-данных и другие. А в сентябре этого года планируется выпустить бета-версию генератора IFC-модели по чертежам❗️

https://ifcsuite.inex.fr/

P.S. При использовании инструмента помните, что загружаете файлы на чужой сервер.

P.P.S. И проверяйте полученный файл несколькими просмотрщиками.

👥 @IFC_ru
👥 @IFC_club

Гибкое создание IFC из Revit еще ближе

ACCA Software анонсировала плагин usBIM.revolution для управления классами и свойствами IFC в Revit.
На видео первые функции плагина, расширяющие Revit в части настройки IFC:
🔹 Гибкая и удобная настройка классификации IFC и свойств;
🔹 Копирование свойств между объектами.

Скоро всё остальное.

👥 @IFC_ru
👥 @IFC_club

О новых «методических рекомендациях» крупными мазками

Вышел ряд проектов приказов Минстроя, касающихся применения ТИМ. Остановимся на самом объемном документе за всю историю отечественного ТИМ-внедрения. 657 листов, и это явно не предел.

🔹 Читая название документа, ожидаешь увидеть методические рекомендации по формированию требований к ЦИМ МКД, но вместо этого внутри мы видим исключительно сами требования к моделям. Методических рекомендаций же в документе нет, хотя это обозначено в области применения.

🔹 Это значит, что стройотрасль получит еще один нормативный документ (утвержденный приказом Минстроя), наряду с СП333 и ПНСТ 909, что в результате приведет к еще большей путанице у заказчиков и исполнителей.

Далее комментарии к самим требованиям:

🔹 В документе описаны цели создания моделей и наборы атрибутивных данных к ним (табл. 1, 2), но такие наборы для каждой цели избыточны. Например, для визуализации процесса строительства (№ п/п 9) нет необходимости в элемент заполнять все свойства из группы "Маркировка". То есть выбранный подход не рационален с точки зрения трудозатрат.

🔹 Не объяснено, какие элементы необходимо моделировать для каждого сценария.

🔹 Документ содержит излишний состав свойств. К примеру, элементы трубы, стр. 322:

- Этаж (RUS_ElementStoreyNumber);
- Номер корпуса (RUS_ElementBuildingNumber);
- Марка системы (RUS_SystemBrand);
- ...

Эти данные не нуждаются в фиксации в виде свойств. Потому как приведет лишь к дополнительным трудозатратам со стороны исполнителя, дублированию данных и возможным ошибкам. Эта информация «вытягивается» с помощью связей, создаваемых в IFC, и группировкой элементов в системы, зоны, и т.д.

🔹 Так называемые «карточки» элементов содержат требования к свойствам в проприетарном формате. Устанавливать это требование на федеральном уровне для всех от лица Минстроя по меньшей мере некорректно. Потому как за годы работы профсообщество накопило огромный ряд плагинов, скриптов, шаблонов проектов, библиотечных элементов, которые работают на конкретных и устоявшихся именах параметров, и за счет которых выстраиваются процессы.

🔹 Документ содержит требования, за которые исполнитель не должен отвечать: Вместе с требованиями к наборам свойств, есть еще и альтернативная группировка свойств, созданная для привязки к ним сценариев (Геометрия, Маркировка, и т.д.). Но читая документ, не становится яснее, как эта группировка реализуется в модели, и нужна ли она там. Если это невозможно, а создается в рамках ПО для анализа ЦИМ, то это не является зоной ответственности проектировщика.

🔹 Нереализуемые требования связаны со свойствами Name, Material, Description, а именно с отсутствием наборов свойств к ним. Свойств без наборов не бывает, это противоречит схеме данных. Но если здесь подразумеваются не свойства элемента, а атрибуты класса, жестко закрепленные схемой IFC, то атрибута Material у объектных классов нет.

🔹 В документе введены новые наборы свойств на английском языке с префиксом RusSet_, а также новые свойства тоже на английском. Какой в этом практический смысл, не объясняется. И хотя стандарт IFC не запрещает вводить новые наборы свойств, но зачем усложнять всем жизнь префиксами и английскими названиями?

🔹 Не ясна логика изображения элементов в «карточках». Правильнее и информативнее изображать элементы в их минимально необходимой детализации, а не фотографией. Профильные специалисты и так прекрасно знают, как выглядят фитинги и унитазы.

И в заключение.

Документ местами схож с ПНСТ 909 по содержанию и смыслу, но всё же это другой документ. Стратегически правильнее было бы:
1. Совместно с ДОМ.РФ и ТК505 дошлифовать ПНСТ до качественного документа;
2. Апробировать его на множестве пилотных проектов, в том числе в регионах страны;
3. Провести анализ на реальную пользу от применения документа, с соответствующими выводами;
4. Дать рекомендации отечественным ПО в части реализации данных требований;
5. Выпустить итоговую редакцию в виде ГОСТ Р, не создавая альтернативу ПНСТ под видом методических рекомендаций.

📢 @ifc_ru