Многие считают формат САПР, в котором они привыкли работать, стандартом отрасли, особенно если вкладывают средства в его использование.
❓ Но может ли проприетарный формат стать полноценным стандартом в части организации данных? Что для этого нужно и почему?
1️⃣ Проблемы специализации.
Строительная отрасль обширна и включает множество типов объектов: здания, мосты, тоннели и другие. Это требует специфических инструментов для работы.
Даже "универсальные" САПР не всегда подходят для узких задач. К примеру, проектирование бревенчатых и каркасных домов в Revit может потребовать скриптов, плагинов или библиотечных элементов. Специализированные программы, вроде Cadwork, SEMA или К3-Коттедж часто эффективнее.
2️⃣ Применение нескольких программ.
В рамках одного проекта часто требуется несколько инструментов. Например, для раздела ГП могут потребоваться другие ПО с собственными форматами. САПР не могут полностью заменить программы для расчётов, смет или проектирования инфраструктуры, что создаёт необходимость интеграции данных из разных источников.
3️⃣ Риск зависимости от проприетарных форматов.
Любой проприетарный формат САПР - это частная закрытая разработка компании. На этом построен ее бизнес. В современном мире это нормально, но пользователь должен понимать все риски такого подхода.
4️⃣ Проблемы с хранением и версионностью.
Проприетарные форматы зачастую могут создавать проблемы долгосрочного хранения данных, и доступ к старым или новым версиям формата может быть затруднён.
5️⃣ Ограничения в схеме данных.
Схема данных в форматах САПР оптимизирована для работы ПО, а не для отражения иерархической структуры объекта. Это может усложнить стандартизацию данных. В открытых стандартах, таких как IFC, предлагается представлять данные в виде онтологии, описывающей логическую иерархию с учетом различных сценариев и задач.
Касаемо схемы есть еще ряд моментов:
➖ Ограниченная классификация элементов.
САПР имеют очень ограниченный набор категорий (например, отделку вынуждены создавать "стеной", а сваю - "колонной"), без возможности их расширения. Это заставляет пользователей применять дополнительную классификацию, записывая коды в параметры.
➖ Ограничения на создание наборов свойств и связей.
Некоторые САПР не позволяют создавать наборы свойств или управлять связями. Приходится создавать условные разделители, вроде этого:
___Параметры квартиры_____
Знакомо?
🔍 Чтобы стать стандартом данных, спецификация формата должна покрывать широкий спектр задач и представлять собой онтологию. При этом она должна быть написана, опубликована и утверждена.
🔍 Проприетарные форматы САПР, включая RVT, не обеспечивают полноценной стандартизации данных (хотя они удобны в работе проектировщика). Для этого требуются дополнительные действия: классификация элементов, маппинг свойств и настройка экспорта.
И открытые стандарты, такие как IFC, здесь играют ключевую роль.
📢 @IFC_ru
👥 @IFC_club