Как правильно выбирать ПО для анализа моделей
Поделимся мыслями для тех, кто рассматривает отечественные ПО для дальнейшего приобретения.
Мы тестировали разные программные продукты. И наш текущий вердикт для них таков:
Но у всех из них есть большой потенциал, ценные функции и неоспоримый плюс: они ближе к нашему пользователю и нашим реалиям.
Так, например, в силу надвигающейся государственной "XML-изации" они быстро сообразят и напишут необходимый инструментарий для работы с XML.
На что следует обратить внимание при выборе ПО:
1️⃣ Отзывчивость разработчика. Во время тестирования и в дальнейшей работе он охотно собирает обратную связь от пользователей, своевременно исправляет баги и добавляет необходимый функционал.
2️⃣ Нацеленность разработчика на удобство и простоту использования. Например, реализовать функционал по обновлению файла в сводной модели можно в 10 кликов, а можно одним кликом или вообще автоматически. Такие мелочи в конечном счете сильно влияют на вашу продуктивность. Сюда же отнесем и приятный интерфейс.
3️⃣ Отказ от изобретения велосипеда. Разработчик понимает, что выдумывать свои "новинки" не имеет смысла, так как большинство пользователей применяли иностранное ПО и привыкли к нему. Разумнее сделать точно так же. Во многих ПО есть функционал, который давно себя зарекомендовал и менять его обычно не приводит ни к чему хорошему. Например, такая простая функция как "видовой куб". Удобно и понятно.
4️⃣ Инновационность. Данный пункт не противоречит предыдущему. Если разработчик ПО ведет работу над новым и перспективным функционалом, к примеру, применение ИИ для работы с моделью или отслеживание изменений в версиях моделей с помощью слайдера, то это большой плюс.
5️⃣ Скорость обработки данных. Проблемы со скоростью есть у всех. Здесь важно понаблюдать, активно ли разработчик работает над ней, увеличивается ли скорость проверок на коллизии, какова быстрота загрузки моделей и так далее.
6️⃣ Приверженность открытым стандартам передачи данных, как фундаменту технологии (#IFC, #BCF, #IDS и т.д.). Это сделает BIM таким, каким он должен быть. Открытым, прозрачным, доступным.
Это же поспособствует и здоровой конкуренции среди ПО, так как в борьбе за клиента разработчик сфокусируется на совершенствовании своих решений, при этом не отрицая мировой опыт применения открытых стандартов.
Есть еще один пункт, но о нем будет отдельный пост.
📢 @IFC_ru
👥 @IFC_club
Поделимся мыслями для тех, кто рассматривает отечественные ПО для дальнейшего приобретения.
Мы тестировали разные программные продукты. И наш текущий вердикт для них таков:
Отечественные ПО для анализа моделей сегодня находятся в стадии бета-тестирования.
Но у всех из них есть большой потенциал, ценные функции и неоспоримый плюс: они ближе к нашему пользователю и нашим реалиям.
Так, например, в силу надвигающейся государственной "XML-изации" они быстро сообразят и напишут необходимый инструментарий для работы с XML.
На что следует обратить внимание при выборе ПО:
Это же поспособствует и здоровой конкуренции среди ПО, так как в борьбе за клиента разработчик сфокусируется на совершенствовании своих решений, при этом не отрицая мировой опыт применения открытых стандартов.
Есть еще один пункт, но о нем будет отдельный пост.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥1
О роли OpenSource наработок в программных продуктах
Как и обещали, седьмой пункт, на который следует обратить внимание при выборе ПО:
7️⃣ Объем OpenSource решений в ПО.
OpenSource-наработки сегодня играют важную роль в развитии IT-продуктов, особенно для индивидуальных разработчиков. И собственные разработки "с нуля" при современном ритме почти не встречаются.
Однако, если проект в большей степени состоит из OpenSource решений, сначала он может быстро и громко выстрелить, но в конечном счете рискует стать крайне неповоротливым, так как будет представлять из себя сборную солянку.
Развитие такого продукта будет затруднено в виду того, что разбираться в OpenSource-библиотеках бывает трудно, и они тянут за собой баги.
Поэтому перед приобретением ПО стоит спросить разработчика, на какой базе развивается его продукт.
Яркий пример такому применению OpenSource-решений: внедрение готовых IFC-вьюеров и BCF-редакторов замечаний в различные платформы.
Для задач простейшего просмотра моделей и замечаний этого может быть достаточно. Но аппетит приходит во время еды, и развитие функционала требует дополнительных усилий разработчиков, так как нужно разбираться, как там что устроено, и исправлять чужие ошибки.
📢 @IFC_ru
👥 @IFC_club
Как и обещали, седьмой пункт, на который следует обратить внимание при выборе ПО:
OpenSource-наработки сегодня играют важную роль в развитии IT-продуктов, особенно для индивидуальных разработчиков. И собственные разработки "с нуля" при современном ритме почти не встречаются.
Однако, если проект в большей степени состоит из OpenSource решений, сначала он может быстро и громко выстрелить, но в конечном счете рискует стать крайне неповоротливым, так как будет представлять из себя сборную солянку.
Развитие такого продукта будет затруднено в виду того, что разбираться в OpenSource-библиотеках бывает трудно, и они тянут за собой баги.
Поэтому перед приобретением ПО стоит спросить разработчика, на какой базе развивается его продукт.
Яркий пример такому применению OpenSource-решений: внедрение готовых IFC-вьюеров и BCF-редакторов замечаний в различные платформы.
Для задач простейшего просмотра моделей и замечаний этого может быть достаточно. Но аппетит приходит во время еды, и развитие функционала требует дополнительных усилий разработчиков, так как нужно разбираться, как там что устроено, и исправлять чужие ошибки.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2🔥1
В ТК 505 стали обсуждать необходимость актуализации СП 333.
На форуме Нанософт «Сила платформы» выдалась возможность объяснить, почему данная инициатива без изменения подхода к написанию требований не возымеет успеха. И что нужно, чтобы поменять сложившуюся ситуацию.
1️⃣ Идти по пути создания универсальных обязательных государственных атрибутов в одном СП - тупиковый путь. Таких атрибутов не существует из-за огромного разнообразия видов ОКС.
И нужно будет либо четко определиться с видами ОКС, что сделает СП более конкретизированным и узконаправленным. Либо полностью исключать атрибутивный состав ввиду регулярно обновляющихся стандартов, из которых эти атрибуты извлекаются.
2️⃣ СП333, исходя из названия, должен описывать правила формирования ИМ ОКС, а не требования к ней. Требования отвечают на вопрос "что?" (должно быть в модели). Правила - на вопрос "как?".
Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."
Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?
Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.
Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.
Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.
В документе должно быть описано, как и каким образом требования должны быть созданы, как определяется их полнота исходя из целей заказчика, форма их представления, структура и схема данных.
Такой подход:
🔹 приведет к единообразию требований к элементам ИМ и ЦИМ, что поспособствует формализации таких требований в цифровую форму.
🔹 будет способствовать плавному и осмысленному переходу к созданию собственных требований заказчика.
🔹 создаст базис для дальнейшего перевода сложных нормативных требований в цифровой вид.
Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.
📢 @IFC_ru
👥 @IFC_club
На форуме Нанософт «Сила платформы» выдалась возможность объяснить, почему данная инициатива без изменения подхода к написанию требований не возымеет успеха. И что нужно, чтобы поменять сложившуюся ситуацию.
И нужно будет либо четко определиться с видами ОКС, что сделает СП более конкретизированным и узконаправленным. Либо полностью исключать атрибутивный состав ввиду регулярно обновляющихся стандартов, из которых эти атрибуты извлекаются.
Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."
Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?
Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.
Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.
Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.
В документе должно быть описано, как и каким образом требования должны быть созданы, как определяется их полнота исходя из целей заказчика, форма их представления, структура и схема данных.
Такой подход:
Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4❤1💯1
Повторяешь информацию в модели?
Раскроем 4ый пункт поста о связах.
Вы наверняка сталкивались с необходимостью наполнения элементов избыточными свойствами.
К примеру, присвоение элементу воздуховода марки инженерной сети приводит к дополнительной работе и возможным ошибкам. Достаточно скопировать элемент, забыть исправить марку системы - и мы получаем расхождение данных.
По мере погружения в структуру IFC появляется понимание, что повторение одних и тех же данных в каждом элементе может быть излишне.
🔍 Эффективнее и проще сгруппировать элементы в систему (IfcDistributionSystem) с помощью связей. Марка задается один раз всей системе и распространяется на вложенные элементы. Так легче отследить корректность данных и уменьшить вероятность ошибок.
И это лишь один из массы подобных примеров. Взять ту же квартирографию. Различные компании написали уже уйму скриптов и плагинов. И все они суть об одном.
✈️ Но почему многие требуют дублировать информацию непосредственно в элемент? И как решить эту проблему?
👥 @ifc_ru
👥 @ifc_club
Раскроем 4ый пункт поста о связах.
Вы наверняка сталкивались с необходимостью наполнения элементов избыточными свойствами.
К примеру, присвоение элементу воздуховода марки инженерной сети приводит к дополнительной работе и возможным ошибкам. Достаточно скопировать элемент, забыть исправить марку системы - и мы получаем расхождение данных.
По мере погружения в структуру IFC появляется понимание, что повторение одних и тех же данных в каждом элементе может быть излишне.
И это лишь один из массы подобных примеров. Взять ту же квартирографию. Различные компании написали уже уйму скриптов и плагинов. И все они суть об одном.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🤔3🔥1
Причины излишнего дублирования данных в модели
В попытках автоматизировать процессы работы с данными остается риск увлечься повторением и перенасыщением элементов избыточной информацией.
Корни этой проблемы лежат в следующем:
1️⃣ Мы слишком поверхностно воспринимаем концепцию, что модель - это элементы с геометрией и свойствами.
Используя модель как источник структурированных данных, например, для автоматизированных проверок, возникает потребность в более глубоком насыщении элементов информацией.
В результате появляются многочисленные СП, ПНСТ и прочие требования, где всё заточено на максимальное наполнение элементов атрибутами. Это вызывает допнагрузку на исполнителей, которым приходится «вручную» контролировать такие данные, что требует неоправданных издержек.
И вторая причина:
2️⃣ Мы упираемся в несовершенства ПО, которые не позволяют организовать более эффективную работу с данными.
Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.
Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.
И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.
При таком подходе проблематично обращаться к данным из других частей модели, связанных с выбранными элементами.
Решение может быть следующим:
🔍 САПР необходимо научиться формировать связи по структуре IFC.
🔍 ПО для анализа моделей (чекеры) должны научиться извлекать данные с применением связей.
Развитие функционала ПО в части соответствия IFC приведет к тому, что проблема излишнего повторения информации снизится. А применение таких возможностей конечным пользователем приведет к пересмотру техзаданий заказчика и нормативных документов.
Раскрытие всего потенциала связей также поспособствует описанию нормативных требований в цифровом виде и дальнейшей автоматизированной проверке на них.
👥 @ifc_ru
👥 @ifc_club
В попытках автоматизировать процессы работы с данными остается риск увлечься повторением и перенасыщением элементов избыточной информацией.
Корни этой проблемы лежат в следующем:
Используя модель как источник структурированных данных, например, для автоматизированных проверок, возникает потребность в более глубоком насыщении элементов информацией.
В результате появляются многочисленные СП, ПНСТ и прочие требования, где всё заточено на максимальное наполнение элементов атрибутами. Это вызывает допнагрузку на исполнителей, которым приходится «вручную» контролировать такие данные, что требует неоправданных издержек.
И вторая причина:
Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.
Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.
И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.
При таком подходе проблематично обращаться к данным из других частей модели, связанных с выбранными элементами.
Решение может быть следующим:
Развитие функционала ПО в части соответствия IFC приведет к тому, что проблема излишнего повторения информации снизится. А применение таких возможностей конечным пользователем приведет к пересмотру техзаданий заказчика и нормативных документов.
Раскрытие всего потенциала связей также поспособствует описанию нормативных требований в цифровом виде и дальнейшей автоматизированной проверке на них.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥1
Ежемесячный подкаст "BIM-среда" в IFC Клубе!
🗓️ Среда, 6 ноября, в 16-00 МСК
🔊 Тема: "IFC для объектов улично-дорожной сети"
Гость:
👤 Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"
Поговорим о:
🛑 применимости IFC для объектов транспортной инфраструктуры;
🛑 требованиях к классификации элементов;
🛑 возможностях экспорта в IFC из отечественных ПО;
🛑 принципах автоматических проверок;
🛑 и перспективах использования IFC-моделей для дорог и улиц.
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
Гость:
Поговорим о:
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
YouTube
#13= IFC для объектов улично-дорожной сети (Дмитрий Ушаков, 6.11.2024)
Ежемесячный подкаст "BIM-среда" в IFC Клубе! (https://xn--r1a.website/IFC_club)
🗓️ Среда, 6 ноября, в 16-00 МСК
🔊 Тема: "IFC для объектов улично-дорожной сети"
Гость:
👤 Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"
Тайминг:
00:01 Введение и представление…
🗓️ Среда, 6 ноября, в 16-00 МСК
🔊 Тема: "IFC для объектов улично-дорожной сети"
Гость:
👤 Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"
Тайминг:
00:01 Введение и представление…
Тайминг:
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 Ответы на вопросы
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥2
Немало копий сломано о непреступную крепость машинно-интерпретируемых требований к моделям. 🤬
1️⃣ Португальские разработчики пробуют свои возможности в создании строительных норм в виде графов с помощью обычных текстовых запросов (первое видео). И очевидно, здесь не обошлось без ИИ.
Запросы переводятся в графовый вид, используя сущности #IFC.
Вопрос, насколько корректно сформировались графы нормативных требований, остается открытым, но выглядит волшебно.
2️⃣ На втором видео пользователь обращается к IFC-модели, представленной в виде графов. В итоге видим преображение графа с акцентом на конкретные элементы, свойства, связи на основе запроса. 🪄
👥 @IFC_ru
👥 @IFC_club
Запросы переводятся в графовый вид, используя сущности #IFC.
Вопрос, насколько корректно сформировались графы нормативных требований, остается открытым, но выглядит волшебно.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8
Новости отечественных 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
- обновлен парсер IFС-файлов, и теперь загрузка моделей будет быстрее.
- добавлен импорт замечаний в формате BCF версий 2.1 и 3.0, а также появилась возможность передачи кубов сечений, размеров и чертежей через формат BCF.
- продолжается работа над полноценной поддержкой стандарта IFC 4х3.
- в фасете Classification можно выбрать нужный классификационный код из таблиц отечественных классификаторов КСИ, РЖД, МССК. Инструмент дорабатывается;
- в фасете Property добавлен выпадающий список стандартных свойств и наборов свойств согласно выбранной версии стандарта IFC.
- работает над поддержкой цифровых требований по стандарту IDS (уже есть первые результаты);
- разрабатывает модуль расширения "API BCF server", с помощью которого работа с BCF-замечаниями будет без использования файлов, отправляя отчеты сразу в САПР.
- улучшенный экспорт в IFC для архитектурных моделей в модуле BIM Строительство;
- расширенный преднастроенный маппинг при выгрузке в IFC по различным требованиям (экспертизы Свердловской области, ПНСТ 909-2024, МГЭ, СПб ГАУ "ЦГЭ", СП 333).
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17👍8⚡1
ТИМ-конгресс 2024. Перспективы ИИ и Реестра цифровых требований
На предстоящем ТИМ-конгрессе 27-28 ноября хочется акцентировать внимание на актуальные секции по внедрению ИИ и по реестру требований. Обе темы требуют научного подхода и серьезной базы. Здесь важно как можно быстрее откинуть слепую веру в чудеса ИИ и завышенные ожидания от быстрого решения вопроса создания реестра цифровых нормативных требований.
🔹 В секции по искусственному интеллекту Виталий Адольфович Семенов, профессор ИСП РАН, выступит с темой «Перспективы применения ИИ для цифровизации нормативных требований в строительстве на основе открытых стандартов» и расскажет о необходимости внедрения математического аппарата для решения задач автоматизации нормативных проверок с привязкой к схеме данных IFC.
🔹 Ольга Кутузова, ООО «Нанософт Разработка», расскажет о «Возможностях автоматизации создания цифровых требований стандартов с помощью технологии ИИ» и большой многолетней работе в этой области.
Импонирует прагматичный и научно-практический подход коллег к этой непростой теме с серьезными наработками и реалистичным взглядом на применение ИИ и его место в области машинно-интерпретируемых требований и обработке проектных данных.
@ifc_ru
На предстоящем ТИМ-конгрессе 27-28 ноября хочется акцентировать внимание на актуальные секции по внедрению ИИ и по реестру требований. Обе темы требуют научного подхода и серьезной базы. Здесь важно как можно быстрее откинуть слепую веру в чудеса ИИ и завышенные ожидания от быстрого решения вопроса создания реестра цифровых нормативных требований.
Импонирует прагматичный и научно-практический подход коллег к этой непростой теме с серьезными наработками и реалистичным взглядом на применение ИИ и его место в области машинно-интерпретируемых требований и обработке проектных данных.
@ifc_ru
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍4
Media is too big
VIEW IN TELEGRAM
Как выгрузить связанные файлы Revit в один IFC
Пользователи Revit часто задают вопрос, можно ли выгружать связанные файлы Revit в общий IFC-файл?
Ответ: можно, но есть нюанс.
1️⃣ Общий IFC-файл следует создавать, только если:
🔹 нужно экспортировать два и более объекта/здания/секции (IfcBuilding), расположенных на одном участке (IfcSite);
🔹 имеем два и более объекта на разных участках.
Это также могут быть здания окружающей застройки, смежные корпуса и так далее.
2️⃣ Создавать общий IFC-файл из связанных смежных разделов в рамках одного проекта не совсем корректно с точки зрения структуры IFC-проекта, хотя и возможно. Потому как в таком случае мы получаем несколько IfcBuilding, наполненных элементами разных дисциплин, но по факту здание всего одно.
👥 @IFC_ru
👥 @IFC_club
Пользователи Revit часто задают вопрос, можно ли выгружать связанные файлы Revit в общий IFC-файл?
Ответ: можно, но есть нюанс.
Это также могут быть здания окружающей застройки, смежные корпуса и так далее.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥5😁2
НОТИМ 2024. Семенов.pdf
1.7 MB
Перспективы ИИ для цифровизации требований в строительстве на основе открытых стандартов
Семенов Виталий Адольфович
зав. отделом ИСП РАН, профессор, доктор физ.-мат. наук,
Институт системного программирования им. В.П. Иванникова РАН
Семенов Виталий Адольфович
зав. отделом ИСП РАН, профессор, доктор физ.-мат. наук,
Институт системного программирования им. В.П. Иванникова РАН
Ничто так не вредит развитию ИИ, как вера в то, что он когда-нибудь полностью заменит человека (В.Л. Арлазаров)
🔥5👍3
Традиционный подкаст в IFC Клубе!
🗓️ В этот раз в четверг, 5 декабря, в 16-00 МСК
🔊 Тема: "Экспертиза без чертежей: ожидания и реальность"
Гость:
👤 Сергей Сербин, главный специалист ГАУ СО "Управление государственной экспертизы" (г. Екатеринбург)
Поговорим о:
🛑 пилотном проекте Свердловской экспертизы по рассмотрению модели без чертежей;
🛑 требованиях, по которым готовилась модель;
🛑 возможностях и проблемах ПО, в котором рассматривалась модель;
🛑 выводах и дальнейших перспективах по итогам амбициозного проекта.
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
👥 @IFC_ru
👥 @IFC_club
Гость:
Поговорим о:
Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍3
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
На наш взгляд, это один из самых важных пилотных проектов, проводимых за последние пару лет. От него не стоит ожидать быстрой отдачи, так как это игра в долгую. Но в конечном итоге результат этой работы может/должен повлечь за собой череду изменений. И вот почему:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
#14= Экспертиза без чертежей: ожидания и реальность (Сергей Сербин, 5.12.2024)
Ежемесячный подкаст в IFC Клубе! (https://xn--r1a.website/IFC_club)
🗓️ 5 декабря, в 16-00 МСК
🔊 Тема: "Экспертиза без чертежей: ожидания и реальност"
Гость:
👤 Сергей Сербин, главный специалист по ТИМ, ГАУ СО "Управление государственной экспертизы"
Поговорили о:…
🗓️ 5 декабря, в 16-00 МСК
🔊 Тема: "Экспертиза без чертежей: ожидания и реальност"
Гость:
👤 Сергей Сербин, главный специалист по ТИМ, ГАУ СО "Управление государственной экспертизы"
Поговорили о:…
👍5🔥2
BIM-форум 2024 завтра!
⚡️ Место: Москва, Amber Plaza, Краснопролетарская 36
Наша подборка докладов на 11 декабря
💎 Главный зал
🔹
🔹
🔹
💎 Большой зал
🔹
🔹
💎 Средний зал
💎 Малый зал
🔹
Наша подборка докладов на 11 декабря
10:30 - 11:10
Состав ЦИМ. Обзор проектов приказов Минстроя России
Драгомиров Сергей, Минэкс
11:50 - 12:10
Проведение экспертизы раздела "АР" только по ЦИМ
Архипович Мария, Сербин Сергей, ГАУ СО "Управление государственной экспертизы"
13:10 - 13:30
Формирование требований к ЦИМ объектов УДС
Ушаков Дмитрий, МКУ "УКС г. Екатеринбурга"
16:30 - 16:50
Разработка и использование машиночитаемых требований заказчика в формате IDS к ЦИМ
Семенцов Павел, Главстрой СПб, Шерстенников Игорь, СПб ГАУ "ЦГЭ"
10:30 - 10:50
Нормативные проверки ЦИМ линейного объекта
Кирюшина Анастасия, Айбим
15:10 - 15:30
BIM-менеджмент. IDS-требования. IFC-интерфейс
Мотовилов Антон, ООО "Желдорпроект"
15:30 - 16:10
XML для чайников
Шерстенников Игорь, СПб ГАУ "ЦГЭ"
15:10 - 15:30
Строительная информация и справочники данных
Бабинов Алексей, WE-ON
11:10 - 11:30
ТИМ и сметы. Зачем нужна классификация и почему IFC не помогает сметчикам?
Воронин Иван, АВС-Н
11:50 - 12:10
Экспертиза ТИМ-смет. Требовния к форматам и данным
Самопал Николай, Визардсофт
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥3
Шерстенников_И_СПбГАУЦГЭ_Интероперабельность_требований_11122024.pdf
528.2 KB
Применение IDS в службе заказчика
Тема машиноинтерпретируемых требований по единой форме проникает в отрасль. Главстрой-СПб представил доклад о том, как идет этот процесс в службе заказчика.
В попытках создавать единый общегосударственный EIR (он же СП333) есть риск создать просто еще один документ, который никого не будет устраивать. Поэтому научиться создавать свои требования в цифровой форме и обмениваться ими даст больший эффект.
К примеру, в САПР может быть реализована возможность автоматизировано выполнять требования, сопоставлять пользовательские свойства согласно им и выгружать в IFC только при соблюдении IDS. Так, DiRoots разработал плагин для работы с IDS в Revit (о нем мы писали ранее).
P.S. Примеры свежих IDS-требований к ЦИМ ОКС и РИИ выложены на сайте СПб ГАУ "ЦГЭ". Они будут периодически дорабатываться и обновляться. Состав немного отличается от "аналогового" варианта.
📢 @IFC_ru
👥 @IFC_club
Тема машиноинтерпретируемых требований по единой форме проникает в отрасль. Главстрой-СПб представил доклад о том, как идет этот процесс в службе заказчика.
В попытках создавать единый общегосударственный EIR (он же СП333) есть риск создать просто еще один документ, который никого не будет устраивать. Поэтому научиться создавать свои требования в цифровой форме и обмениваться ими даст больший эффект.
К примеру, в САПР может быть реализована возможность автоматизировано выполнять требования, сопоставлять пользовательские свойства согласно им и выгружать в IFC только при соблюдении IDS. Так, DiRoots разработал плагин для работы с IDS в Revit (о нем мы писали ранее).
P.S. Примеры свежих IDS-требований к ЦИМ ОКС и РИИ выложены на сайте СПб ГАУ "ЦГЭ". Они будут периодически дорабатываться и обновляться. Состав немного отличается от "аналогового" варианта.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3