Простой способ сравнения версий модели

🔍 С помощью Get The Code от That Open Company появляется возможность создавать инновационное и в то же время простое решение, позволяющие загружать две версии модели в просмотрщик и сравнивать их, передвигая слайдер.

Благодаря ему сравнение геометрии в модели #IFC становится более удобным и простым.

✈️ Так, открытые решения помогают индивидуальным разработчикам внедрять функционал, который им необходим, без лишних затрат и с адаптацией под свои задачи, предпочитая максимальную свободу в развитии продукта. А появление на рынке удобных инструментов на базе OpenSource стимулирует коммерческих разработчиков ПО к более активной работе над улучшением своих BIM-продуктов.

Если вы видели подобную функцию в каком-либо ПО, напишите в комментариях.

📢 @IFC_ru
👥 @IFC_club

🔍 BIMчат с моделью с помощью ИИ. Двигаемся дальше.

Помните проект по внедрению ИИ для работы с данными в модели?

Дарья Гречишникова (ВитроСофт), победитель конкурса ТИМ-лидеры 2024, добралась до того, что найденные по запросу элементы теперь отображаются во вьюере. А по полученным таблицам можно найти нужный элемент, воспользовавшись поиском.

Также есть возможность поправить сгенерированный код руками и запустить его снова.

Это ли не круто, коллеги? И все это делает один человек (а мы немножко тестируем).

Всё еще достаточно сырое, и много предстоит дорабатывать. Но тут важен сам факт, что это работает.

Такие решения делают информацию о проекте более доступной конечным пользователям, которые с BIM-технологиями на "Вы". Остается лишь научиться корректно писать запросы.

📢 @IFC_ru
👥 @IFC_club

Как правильно выбирать ПО для анализа моделей

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

Мы тестировали разные программные продукты. И наш текущий вердикт для них таков:

Отечественные ПО для анализа моделей сегодня находятся в стадии бета-тестирования.

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

Так, например, в силу надвигающейся государственной "XML-изации" они быстро сообразят и напишут необходимый инструментарий для работы с XML.

На что следует обратить внимание при выборе ПО:

1️⃣ Отзывчивость разработчика. Во время тестирования и в дальнейшей работе он охотно собирает обратную связь от пользователей, своевременно исправляет баги и добавляет необходимый функционал.

2️⃣ Нацеленность разработчика на удобство и простоту использования. Например, реализовать функционал по обновлению файла в сводной модели можно в 10 кликов, а можно одним кликом или вообще автоматически. Такие мелочи в конечном счете сильно влияют на вашу продуктивность. Сюда же отнесем и приятный интерфейс.

3️⃣ Отказ от изобретения велосипеда. Разработчик понимает, что выдумывать свои "новинки" не имеет смысла, так как большинство пользователей применяли иностранное ПО и привыкли к нему. Разумнее сделать точно так же. Во многих ПО есть функционал, который давно себя зарекомендовал и менять его обычно не приводит ни к чему хорошему. Например, такая простая функция как "видовой куб". Удобно и понятно.

4️⃣ Инновационность. Данный пункт не противоречит предыдущему. Если разработчик ПО ведет работу над новым и перспективным функционалом, к примеру, применение ИИ для работы с моделью или отслеживание изменений в версиях моделей с помощью слайдера, то это большой плюс.

5️⃣ Скорость обработки данных. Проблемы со скоростью есть у всех. Здесь важно понаблюдать, активно ли разработчик работает над ней, увеличивается ли скорость проверок на коллизии, какова быстрота загрузки моделей и так далее.

6️⃣ Приверженность открытым стандартам передачи данных, как фундаменту технологии (#IFC, #BCF, #IDS и т.д.). Это сделает BIM таким, каким он должен быть. Открытым, прозрачным, доступным.

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

Есть еще один пункт, но о нем будет отдельный пост.

📢 @IFC_ru
👥 @IFC_club

О роли OpenSource наработок в программных продуктах

Как и обещали, седьмой пункт, на который следует обратить внимание при выборе ПО:

7️⃣Объем OpenSource решений в ПО.

OpenSource-наработки сегодня играют важную роль в развитии IT-продуктов, особенно для индивидуальных разработчиков. И собственные разработки "с нуля" при современном ритме почти не встречаются.

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

Развитие такого продукта будет затруднено в виду того, что разбираться в OpenSource-библиотеках бывает трудно, и они тянут за собой баги.

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

Яркий пример такому применению OpenSource-решений: внедрение готовых IFC-вьюеров и BCF-редакторов замечаний в различные платформы.

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

📢 @IFC_ru
👥 @IFC_club

В ТК 505 стали обсуждать необходимость актуализации СП 333.

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

1️⃣ Идти по пути создания универсальных обязательных государственных атрибутов в одном СП - тупиковый путь. Таких атрибутов не существует из-за огромного разнообразия видов ОКС.

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

2️⃣ СП333, исходя из названия, должен описывать правила формирования ИМ ОКС, а не требования к ней. Требования отвечают на вопрос "что?" (должно быть в модели). Правила - на вопрос "как?".

Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."

Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?

Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.

Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.

Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.

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

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

Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.

📢 @IFC_ru
👥 @IFC_club

Повторяешь информацию в модели?

Раскроем 4ый пункт поста о связах.

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

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

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

🔍 Эффективнее и проще сгруппировать элементы в систему (IfcDistributionSystem) с помощью связей. Марка задается один раз всей системе и распространяется на вложенные элементы. Так легче отследить корректность данных и уменьшить вероятность ошибок.

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

✈️ Но почему многие требуют дублировать информацию непосредственно в элемент? И как решить эту проблему?

👥 @ifc_ru
👥 @ifc_club

Причины излишнего дублирования данных в модели

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

Корни этой проблемы лежат в следующем:

1️⃣ Мы слишком поверхностно воспринимаем концепцию, что модель - это элементы с геометрией и свойствами.

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

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

И вторая причина:

2️⃣ Мы упираемся в несовершенства ПО, которые не позволяют организовать более эффективную работу с данными.

Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.

Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.

И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.

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

Решение может быть следующим:
🔍САПР необходимо научиться формировать связи по структуре IFC.
🔍ПО для анализа моделей (чекеры) должны научиться извлекать данные с применением связей.

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

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

👥 @ifc_ru
👥 @ifc_club

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

🗓️ Среда, 6 ноября, в 16-00 МСК

🔊 Тема: "IFC для объектов улично-дорожной сети"

Гость:
👤 Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"

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

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

👥 @IFC_ru
👥 @IFC_club

Применение стандарта IFC для объектов улично-дорожной сети (Дмитрий Ушаков, МКУ "УКС г. Екатеринбурга")

👥 @IFC_ru
👥 @IFC_club

✈️ Запись прошедшего эфира "BIM-среда"

✈️ Тема: Использование стандарта IFC для объектов улично-дорожной сети
✈️ Гость: Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"

📹 Youtube
📺 Rutube

✈️ Презентация

Тайминг:
00:01 Введение и представление докладчика
01:29 Основная деятельность Дмитрия
04:12 Специфика работы с улицами
06:26 Использование стандарта IFC
08:09 Развитие отечественных программ
10:49 Проблемы и решения
11:41 Введение в IFC
12:54 Примеры использования классов и предопределенных типов
13:55 Проблемы с детализацией моделей
15:22 Дорожные знаки и текстуры
17:18 Земляные работы и дорожная одежда
20:31 Маппинг и стандартизация
22:40 Вопросы по маппингу
25:00 Возможности экспорта и маппинга в Кредо
26:21 Маппинг и классы в Кредо
27:13 Различия в обработке 2D и 3D информации
28:43 Проблемы с геометрией и атрибутами
30:38 Необходимые функциональные возможности
33:53 Программное обеспечение для проверки
36:56 Бесплатные просмотрщики IFC
38:29 Проверка цифровой модели
39:22 Ручная и автоматическая проверка
41:30 Проверка атрибутов и объемов
43:30 Коллизии, проверка, автоматизация
50:38 Заключение
50:54 Ответы на вопросы

Новости отечественных BIM продуктов по поддержке открытых стандартов передачи данных.

1️⃣ Renga добавила возможность выгрузки модели в IFC по дисциплинам.

2️⃣ BIMIT улучшил поддержку стандартов IFC и BCF, а именно:
- обновлен парсер IFС-файлов, и теперь загрузка моделей будет быстрее.
- добавлен импорт замечаний в формате BCF версий 2.1 и 3.0, а также появилась возможность передачи кубов сечений, размеров и чертежей через формат BCF.
- продолжается работа над полноценной поддержкой стандарта IFC 4х3.

3️⃣ IDS-редактор цифровых требований от Института системного программирования РАН обновился. Теперь при составлении требования:
- в фасете Classification можно выбрать нужный классификационный код из таблиц отечественных классификаторов КСИ, РЖД, МССК. Инструмент дорабатывается;
- в фасете Property добавлен выпадающий список стандартных свойств и наборов свойств согласно выбранной версии стандарта IFC.

4️⃣ Pilot BIM представил дорожную карту развития, согласно которой:
- работает над поддержкой цифровых требований по стандарту IDS (уже есть первые результаты);
- разрабатывает модуль расширения "API BCF server", с помощью которого работа с BCF-замечаниями будет без использования файлов, отправляя отчеты сразу в САПР.

5️⃣ Tangl стал поддерживать загрузку моделей в формате IFCzip. А после проведения пилотника с экспертизой Свердловской области научился создавать настраиваемые марки для элементов, подхватывая информацию из свойств IFC-элементов (по аналогии с марками на чертежах).

6️⃣ nanoCAD наряду с поддержкой BCF и увеличением скорости загрузки IFC добавил:
- улучшенный экспорт в IFC для архитектурных моделей в модуле BIM Строительство;
- расширенный преднастроенный маппинг при выгрузке в IFC по различным требованиям (экспертизы Свердловской области, ПНСТ 909-2024, МГЭ, СПб ГАУ "ЦГЭ", СП 333).

✅ Отечественный OpenBIM активно развивается. Ведущие разработчики BIM ПО хорошо осознают, что это дает свои преимущества и плоды. Это подтверждение тому, что открытые стандарты на основе IFC являются неотъемлемой частью современного мира BIM и имеют принципиальное значение в цифровизации стройотрасли. И их значимость будет только нарастать.

👥 @IFC_ru
👥 @IFC_club

ТИМ-конгресс 2024. Перспективы ИИ и Реестра цифровых требований

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

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

🔹 Ольга Кутузова, ООО «Нанософт Разработка», расскажет о «Возможностях автоматизации создания цифровых требований стандартов с помощью технологии ИИ» и большой многолетней работе в этой области.

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

@ifc_ru

Как выгрузить связанные файлы Revit в один IFC

Пользователи Revit часто задают вопрос, можно ли выгружать связанные файлы Revit в общий IFC-файл?

Ответ: можно, но есть нюанс.

1️⃣ Общий IFC-файл следует создавать, только если:
🔹 нужно экспортировать два и более объекта/здания/секции (IfcBuilding), расположенных на одном участке (IfcSite);
🔹 имеем два и более объекта на разных участках.

Это также могут быть здания окружающей застройки, смежные корпуса и так далее.

2️⃣ Создавать общий IFC-файл из связанных смежных разделов в рамках одного проекта не совсем корректно с точки зрения структуры IFC-проекта, хотя и возможно. Потому как в таком случае мы получаем несколько IfcBuilding, наполненных элементами разных дисциплин, но по факту здание всего одно.

👥 @IFC_ru
👥 @IFC_club

Традиционный подкаст в IFC Клубе!

🗓️ В этот раз в четверг, 5 декабря, в 16-00 МСК

🔊 Тема: "Экспертиза без чертежей: ожидания и реальность"

Гость:
👤 Сергей Сербин, главный специалист ГАУ СО "Управление государственной экспертизы" (г. Екатеринбург)

Поговорим о:
🛑пилотном проекте Свердловской экспертизы по рассмотрению модели без чертежей;
🛑требованиях, по которым готовилась модель;
🛑возможностях и проблемах ПО, в котором рассматривалась модель;
🛑выводах и дальнейших перспективах по итогам амбициозного проекта.

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

👥 @IFC_ru
👥 @IFC_club