"Иной формат с открытой спецификацией"
(Дополнение к предыдущему посту о проекте ПП РФ 1431)

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

💻 С технической точки зрения, применяя формулировку о «ином формате с открытой спецификацией» в новом проекте ех.ПП РФ 1431, еще раз отметим, что открытых форматов масса. Сегодня мы видим как различные разработчики предлагают свои форматы для хранения и обмена данными. К примеру:

🛑XPG – от СиСОФТ;
🛑IMC – от АЙБИМ, используемый в ПО Larix.Manager (спецификация формата в открытый доступ не выложена);
🛑TopoXML и CredoXML – от Кредо Диалог, выпущенный для замены LandXML;
🛑TIMML – от АРСИТИМ, свежий формат для обмена сметными данными с дополнениями для увязки с элементами модели;
🛑DWF и DWFx - от Autodesk (не развивается).

Список можно продолжать.

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

💻 Говоря о юридической стороне, то к формулировке об "ином формате с открытой спецификацией" также имеется ряд вопросов:

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

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

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

👥 @IFC_ru
👥 @IFC_club

"Мы говорим на одном языке"

Нидерландцы перевели Базовое руководство по доставке информации на разные языки. Причем и на русский перевели весьма неплохо.

Источник: https://www.digigo.nu/ilsen-en-richtlijnen/bim-basis-ils/downloads

#IDS
#База

📢 @ifc_ru
👥 @ifc_club

Поясняем за IFC. Часть 1

На канале Просто о BIM выложен пост об IFC. Процитируем и прокомментируем некоторые моменты, чтобы никого не вводить в заблуждение.

В России Минстрой пытается строить ТИМ (BIM) без привязки к Revit, на IFC.

🆙 Не совсем. Минстрой делает ставку на XML-схемы отечественной разработки для передачи данных в ГИСОГД РФ. А пока для BIM-моделей их нет, то решено опираться на схему IFC (как временное решение).

[В IFC] также для классов предусмотрены IfcType для их расшивки какбы в подклассы.

🆙 Будем считать это неточностью автора. Но так или иначе, сущности IfcType в IFC не существует. У большинства "объектных" классов имеется атрибут PredefinedType, с помощью которого возможно расширение подтипов IFC, используя значение USERDEFINED.

IFC помимо наборов параметров к каждому классу также описывает и геометрию.

🆙 Это далеко не всё. Одним из главных преимуществ IFC является наличие связей IfcRelationship. Кроме того, помимо «объектных» классов, IFC может содержать информацию о сметах, календарно-сетевом планировании, аннотации и многое другое. Подробнее в подкасте "BIM-среда".

Но практика показала что конвертация через IFC недостаточно стабильна, чтобы на нее опираться. При этом, основная притензия к конвертации именно к Revit, мол Autodesk специально делает плохо чтобы сделать подход OpenBIM нерабочим.

🆙 Проблема плохой конвертации связана с тем, что изначально Ревит разрабатывался частной компанией без учета стандарта IFC. При этом сам IFC разрабатывался в 90-е годы во многом благодаря Autodesk. А когда Autodesk купил ревит в начале 2000-х, IFC-совместимости там фактически не было.

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

По большому счету над серьезной поддержкой IFC в Ревите задумались совсем недавно. Когда востребованность в качественном IFC в мире стала возрастать, Autodesk присоединился к альянсу ODA в надежде улучшить возможности экспорта.
Однако Ревит поддерживает только часть возможностей IFC, и то с применением ''костылей''.

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

🆙 В IFC существуют различные типы геометрических представлений, в том числе выдавливание профиля, brep, nurbs и т.д., а также вложенность компонентов. Описываемая проблема - это вопрос корректной работы транслятора в Ревите.

Продолжение далее 👉

#Мифология

Поясняем за IFC. Часть 2

Но такую [mesh и brep] геометрию крайне затруднительно затем воспроизвести обратно в элементы выдавливания (Solid геометрию), т.е. использовать для конвертации и передачи между программами редактируемых компонентов.

🆙 Очевидная вещь, которую нужно понимать, для каких целей модель переводится в IFC:
когда вы преобразуете описание геометрии до примитивного уровня, вернуть ее на более высокий уровень вряд ли удастся.

Т.е. при конвертации IFC как BREP геометрия мы получаем такой же формат как NWC, SVF (Forge), формат программ Revizto, Tangl или Larix.

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

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

В IFC классы нужны именно для задания перечня и форматов атрибутов.

🆙 Классы нужны для стандартизации данных в модели, что позволит однозначно понимать их различными ПО.

Т.е. [IFC модель с] мертвой не параметрической геометрией ... далее не подлежит редактированию без исходного формата

🆙 Вернемся к самому началу поста.
Минстрою и государству модели нужны НЕ для редактирования на всем жизненном цикле, а для передачи их в ГИСОГД и далее для анализа и хранения этих данных. В этом ключе использование IFC с "мертвой" геометрией не влечет за собой никаких рисков.

Напротив, с открытыми данными можно работать в любой момент времени, в отличие от использования закрытых нативных форматов.

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

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

#Мифология

👥 @IFC_ru
👥 @IFC_club

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

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

🔊 Тема: "IFC для инфраструктуры: практические кейсы в Civil 3D"

Гость:
👤 Ярослав Демичев, руководитель BIM-отдела, АО "Мегамейд"

Поговорим о:
🛑применении IFC в инфраструктурных проектах;
🛑принципах и нюансах экспорта в IFC2x3 и IFC4x3 из Civil 3D;
🛑особенностях IFC4x3.

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

👥 @IFC_ru
👥 @IFC_club

IFC4x3 официально опубликован в качестве стандарта ISO

🛑Международная организация по стандартизации ISO официально опубликовала стандарт IFC4x3 как
ISO 16739-1:2024 Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries.

🛑Документ выступает в качестве открытого международного стандарта для представления данных, используемых в информационном моделировании объектов строительства.

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

🛑Настоящее издание расширено в части описания инфраструктурных объектов, включая мосты, автомобильные и железные дороги, водные пути и портовые сооружения.

🛑Документ включает в себя публикацию схемы данных IFC, документацию по ней, определения наборов свойств и количественных показателей, а также механизм структуры форматов файлов обмена.

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

📢@IFC_ru

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

✈️ Гость: Ярослав Демичев, Руководитель BIM-отдела, АО "Мегамейд"

✈️ Сcылки на используемые в докладе материалы:
https://clck.ru/39sRbx
https://clck.ru/39sRcQ

✈️ Дополнение:
Экспортированная модель в IFC4x3.

@IFC_ru
@IFC_club

🌐buildingSMART в Казахстане!

11 марта 2024 года было одобрено создание казахстанского отделения buildingSMART на базе КазНИИСА.

По словам Александра Шахновича, впереди большая работа по адаптации методологии bS и ее мягкому внедрению на практике в Казахстане.

Улучшения IFC-экспорта в Revit 2025

🔍 Из значимого:
🔍 Добавлена возможность экспорта в версию IFC4х3 (по ISO 16739-1:2024).
При этом можно выбирать тип объекта, поскольку в схеме IFC4х3 поддерживаются не только здания (IfcBuilding), но и дороги, мосты, железные дороги, портовые сооружения.

🔍 В некоторых случаях повышена производительность до 50% при экспорте в IFC.

🔍 В части валидности файлов:
🔍 Повышена валидность всех экспортируемых файлов IFC за счет улучшения способа хранения единиц измерения.

🔍 Улучшена корректность файлов при экспорте элементов с составными конструкциями.

🔍 Из удобств:
🔍 Стало приятнее управление таблицами сопоставления категорий для экспорта в IFC.

🔍 В части выгрузки элементов:
🔍 Добавлена поддержка экспорта предопределенных типов при экспорте помещений в IFC 4 и выше (разве ее раньше не было?).

🔍 Решены проблемы с экспортом элементов, созданных "ребром плиты". Их, а также выступающие элементы стен, теперь можно выгружать в любой допустимый класс. Это же касается и элементов, созданных "витражами".

🔍 Исправлен экспорт пользовательского PredefinedType для элемента лестницы.

🔍 Добавлена возможность выборочного запрета экспорта сборок в виде контейнеров в IFC и исправлена обработка параметра Экспорт в IFC для сборок. Улучшен экспорт некоторых элементов, размещенных внутри сборок.

🔍 Улучшен экспорт наклонных перекрытий, балок, проемов и окон в стенах, а также некоторых "твердых" тел в IFC, которые ранее экспортировались как поверхности.

🔍 Улучшения в части свойств:
🔍 Улучшен экспорт вещественных свойств в соответствии с единицами измерения, отображаемыми в Revit, если это возможно.

🔍 Добавлен экспорт пользовательских свойств, содержащих несколько значений, таких как список, таблица и ограниченные значения. (Остается узнать, как загнать в атрибут ревита целую таблицу?).

🔍 Также скорректированы расчеты объема и площади поверхности стен с проемами в IFC4 и расчет свойств высоты и ширины проемов.

Все улучшения тут.

#Практика

@ifc_ru
@ifc_club

Что дает поддержка IFC4x3 в Revit

Revit де-факто является основным инструментом BIM моделирования. В связи с этим несколько наблюдений по поводу поддержки IFC4x3 и улучшений, о которых мы писали выше.

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

🔹 Autodesk, хоть и неохотно, но продолжает от версии к версии налаживать работу с IFC. Это значит, что востребованность IFC растёт, и там это понимают. Но костыли, при помощи которых до сих пор приходится налаживать процесс экспорта, показывают различия между структурой Ревит и IFC. К примеру, пользователям до сих пор приходится объединять помещения в зоны (IfcZone) c помощью добавления параметров в помещения. Хотя по логике объединение в зоны должно происходить инструментом вроде групп, которым бы назначался класс IfcZone, но такой трюк не проходит.

🔹 Поддержка IFC4x3 способствует позиционированию Revit как универсального продукта, подходящего не только для проектирования зданий, но также и инфраструктурных объектов. Кстати, тут есть над чем задуматься и некоторым отечественным продуктам, если они хотят выглядеть конкурентно способными.

🔹 Продолжает работу по IFC не только Autodesk. Например, Sketchup, инструмент изначально далекий от BIM, также улучшает возможности импорта и экспорта IFC, и в новой 2024 версии появилась поддержка PredefinedType для классов и единиц измерений для атрибутов. Такие решения как Blender и Sketchup, постепенно обрастают возможностями структуризации и стандартизации строительных данных, превращаясь в "BIM-помощников" для пользователей (о полноценных BIM-продуктах пока рано говорить).

#Практика

@ifc_ru
@ifc_club

Вспомните эту картинку, когда вам скажут, что закрытые нативные форматы важнее открытых.

Данная ситуация может произойти с любым ПО, и необязательно из-за блокировок компанией-разработчиком. Если сегодня вы отделались легким испугом, то завтра может быть все куда серьезнее.

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

Список можно продолжить.

Отдавать результаты своей работы под контроль IT-компании - сомнительное решение в текущих условиях, не правда ли?
И создание перечня «доверенного» ПО не решит проблему.

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

Одним из звеньев сохранности данных является представление их в открытых форматах. Именно поэтому применение открытых стандартов, доступных всем и всегда, должны быть в приоритете.

Только при обязательном использовании открытых стандартов на качественном уровне будут созданы условия сохранности строительных данных.

Поэтому на государственном уровне важно:
🔹 Обновить ГОСТ Р 10.0.02-2019 до актуального международного стандарта ISO 16739-1:2024;
🔹 Проводить независимую оценку/сертификацию ПО на качественную поддержку этого стандарта (что также поспособствует здоровой конкуренции).

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

@ifc_ru
@ifc_club

Autodesk и Nemetschek Group объявили о соглашении по улучшению совместимости между своими облачными и настольными решениями.

В отечественных новостных лентах событию не уделили внимания в связи с официальным отсутствием крупнейших САПР-компаний в России.

✈️В статье САПР-гигантов упомянулось о приверженности обеих компаний принципам открытых стандартов OpenBIM для достижения интероперабельности, однако ни слова не сказано каким образом в рамках соглашения эти принципы будут соблюдаться.

✈️В опубликованной новости уже заявили об "историческом шаге" для строительной отрасли и многих пользователей ПО. Хотя обычно заявлять об историчности события стоит лишь после достижения значимого результата, пожалуй ожидать настоящей приверженности открытым стандартам здесь не приходится.

✈️Отметим лишь то, что компании-гиганты делают такие шаги не просто так. Так почему это происходит?
Не потому ли, что появляются новые OpenSource-проекты, такие как BlenderBIM, Speckle и другие?
И чтобы удержать пользователей и отвлечь их от роста популярности такого рода решений на базе OpenSource и OpenBIM, гиганты вынуждены прибегать к сотрудничеству в области совместимости продуктов?

Учтут ли мировой опыт российские производители САПР или будут предлагать новые открытые форматы? А может быть стоит просто придерживаться открытых стандартов ИСО?

@ifc_ru
@ifc_club

Принцип наследования в IFC.

Говоря о BIM-моделях как об объектно-ориентированных сущностях, нужно отдавать себе отчет, что под этим понимается. Поясним на принципах смежной области - объектно-ориентированном программировании (ООП). Рассмотрим принцип наследования. Согласно ему классы в IFC выстроены в четкую иерархию родителей и потомков.

✈️ Базовым корневым классом в IFC является IfcRoot. Остальные классы делятся на потомков класса IfcRoot и независимых от него.

✈️ Классы-потомки, представленные в модели, как правило, важны для пользователей. Такие сущности наследуют от "корня" атрибуты GlobalID, OwnerHistory, Name, Description.
GlobalID - обязательный атрибут для уникального идентификатора, обычно создаваемый автоматически в САПР. С помощью атрибутов GlobalID и Name пользователь может отслеживать классы в проекте.

✈️ Классы, не привязанные к ветке IfcRoot, используются для хранения данных, не нуждающихся в глобальном идентификаторе. Обычно такие классы играют вспомогательную или обслуживающую роль. Это могут быть типы геометрических представлений для объектов, цвета, материалы, внешняя информация, явно не представленная в модели (информация о классификации, метаданные внешних документов и так далее).

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

✈️ Некоторые атрибуты обязательны для заполнения. Без них нарушается целостность файла. Если атрибут опциональный, то в структуре файла IFC на его месте ставится знак $.
Например:

#28= IFCPROJECT('3fkehi1_vATQtuYaU0$Grr',$,$,$,$,$,$,(#5),#27);

Здесь у IfcProject заполнен только обязательный GlobalID, и две ссылки на другие сущности. Остальные опциональные атрибуты не заполнены.

#База
@ifc_ru

Три кита IFC

Продолжаем разбор стандарта IFC.
От IfcRoot происходят 3 базовых абстрактных потомка, наследующих его атрибуты:

🔹 IfcObjectDefinition - супертип для всех основных классов IFC, описывающих объект строительства.

🔹 IfcPropertyDefinition - обобщение для свойств и количественных показателей, а также их наборов и шаблонов.

🔹 IfcRelationship - отвечает за отношения/связи между объектами. Связи создаются для добавления отношений между объектами без необходимости изменять сами объекты.

Базовый принцип описания объекта в модели выглядит следующим образом:
🔍 Чтобы определить объект/элемент, достаточно присвоить ему неабстрактный класс-потомок от корня IfcRoot с обязательным атрибутом GUID.

Все остальное по сути дополняет его для полноты данных в модели:
- выстраивание связей с другими сущностями;
- наполнение другими атрибутами;
- добавление наборов свойств;
- формирование геометрии;
- расположение в пространстве.

То есть возможно обойтись и без геометрии и координации элемента. За это отвечают классы, не относящиеся к корню IfcRoot и не имеющие обязательного GUID, но привязанные к объекту с помощью ссылок.

#База
@ifc_ru

🔍 Схема стандарта IDS была доработана до версии 0.9.7, которая по заявлениям разработчиков будет обновлена без изменений до редакции 1.0 и утверждена в качестве официального стандарта buildingSMART.

Что поменялось?
🔍 Незначительно изменили имена и атрибуты элементов;
🔍 Перенесли обязательность/опциональность спецификации на уровень контекста;
🔍 Ушли от ''min max Occurs'' для обозначения обязательности/опциональности требований, введя два новых типа данных.

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

🔍 В связи с этим возникли трудности с переводом старых IDS-требований до новой версии.

🔍 На помощь пришли разработчики отечественного IDS-редактора из Института системного программирования РАН и сделали скрипт по переводу ранее созданных IDS-файлов к схеме 0.9.7.

✈️ Скачать скрипт с официального сайта.

#IDS
@ifc_ru

Определение объектов в IFC

Продолжаем разбор базовых концепций стандарта.
Как мы уже говорили ранее, абстрактный класс IfcObjectDefinition является потомком IfcRoot. Он обобщает все основные классы IFC, описывающие объект строительства.

Этот класс имеет три потомка, которые в свою очередь разветвляются на большую сеть классов:

🔹 IfcContext - ветка, содержащая всего два класса:
IfcProject - определяет общий проект для задания единых координат и единиц измерения. В файле модели может быть создан только один IfcProject.
IfcProjectLibrary - определяет библиотеки проекта.

🔹 IfcObject - ветка, содержащая физические и виртуальные элементы в здании (стены, помещения и т.д.), их объединения в группы, а также процессы, ресурсы и участников.

🔹 IfcTypeObject - ветка, содержащая те же классы, что и IfcObject, но с припиской “Type”. Они используются для создания типов объектов. Это по сути аналог типоразмеров семейств в Revit с их свойствами типа.

Чаще всего наиболее востребованными оказываются потомки IfcProduct, необходимые для задач создания модели здания.

Большинство САПР поддерживают выгрузку в эти классы. Но для других задач, например, для календарно-сетевого планирования и подсчета затрат, потребуется применение иных классов и обычно иного ПО.

В этой связи IFC позиционируется не только как стандарт для представления строительных элементов здания, но и для задач планирования, закупок, строительства и эксплуатации объекта.

#База
@ifc_ru