Причины излишнего дублирования данных в модели
В попытках автоматизировать процессы работы с данными остается риск увлечься повторением и перенасыщением элементов избыточной информацией.
Корни этой проблемы лежат в следующем:
1️⃣ Мы слишком поверхностно воспринимаем концепцию, что модель - это элементы с геометрией и свойствами.
Используя модель как источник структурированных данных, например, для автоматизированных проверок, возникает потребность в более глубоком насыщении элементов информацией.
В результате появляются многочисленные СП, ПНСТ и прочие требования, где всё заточено на максимальное наполнение элементов атрибутами. Это вызывает допнагрузку на исполнителей, которым приходится «вручную» контролировать такие данные, что требует неоправданных издержек.
И вторая причина:
2️⃣ Мы упираемся в несовершенства ПО, которые не позволяют организовать более эффективную работу с данными.
Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.
Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.
И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.
При таком подходе проблематично обращаться к данным из других частей модели, связанных с выбранными элементами.
Решение может быть следующим:
🔍САПР необходимо научиться формировать связи по структуре IFC.
🔍ПО для анализа моделей (чекеры) должны научиться извлекать данные с применением связей.
Развитие функционала ПО в части соответствия IFC приведет к тому, что проблема излишнего повторения информации снизится. А применение таких возможностей конечным пользователем приведет к пересмотру техзаданий заказчика и нормативных документов.
Раскрытие всего потенциала связей также поспособствует описанию нормативных требований в цифровом виде и дальнейшей автоматизированной проверке на них.
👥 @ifc_ru
👥 @ifc_club
В попытках автоматизировать процессы работы с данными остается риск увлечься повторением и перенасыщением элементов избыточной информацией.
Корни этой проблемы лежат в следующем:
1️⃣ Мы слишком поверхностно воспринимаем концепцию, что модель - это элементы с геометрией и свойствами.
Используя модель как источник структурированных данных, например, для автоматизированных проверок, возникает потребность в более глубоком насыщении элементов информацией.
В результате появляются многочисленные СП, ПНСТ и прочие требования, где всё заточено на максимальное наполнение элементов атрибутами. Это вызывает допнагрузку на исполнителей, которым приходится «вручную» контролировать такие данные, что требует неоправданных издержек.
И вторая причина:
2️⃣ Мы упираемся в несовершенства ПО, которые не позволяют организовать более эффективную работу с данными.
Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.
Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.
И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.
При таком подходе проблематично обращаться к данным из других частей модели, связанных с выбранными элементами.
Решение может быть следующим:
🔍САПР необходимо научиться формировать связи по структуре IFC.
🔍ПО для анализа моделей (чекеры) должны научиться извлекать данные с применением связей.
Развитие функционала ПО в части соответствия IFC приведет к тому, что проблема излишнего повторения информации снизится. А применение таких возможностей конечным пользователем приведет к пересмотру техзаданий заказчика и нормативных документов.
Раскрытие всего потенциала связей также поспособствует описанию нормативных требований в цифровом виде и дальнейшей автоматизированной проверке на них.
👥 @ifc_ru
👥 @ifc_club