Репост из: Всё про IFC
Разбираем ТЗ на ЦИМ. Выпуск 5
Проблема LOD
Продолжая тему целей в ТЗ разберем ключевую проблему LOD. На представленных примерах видно, что эта концепция часто работает не как рабочий инструмент, а как источник хаоса.
🔹Ни в одном ТЗ, что приходилось видеть, LOD не применяется единообразно. Каждый изобретает свой подход, что сводит пользу концепции к минимуму.
🔹Кроме того, не указываются способы представления геометрии. Нужен ли элемент как Brep или solid? Или достаточно mesh? (А если меsh, то какая плотность сетки полигонов?).
🔹Связано это с тем, что использование LOD без привязки к конкретным целям, без четкого понимания, кому и зачем это нужно, вызывает больше путаницы, чем порядка.
Если цель - "получение ПД" (без конкретики), то проработка элементов с большой вероятностью не будет соответствовать тому, что вы ожидаете. А если главная задача в ТЗ - "повышение эффективности проектирования", то это не задача, а получаемый эффект. Поэтому важно исходить из требований к конкретной информации, которую необходимо получить.
Это поняли разработчики ISO 19650 и ввели понятие Level of Information Need и выпустили ISO 7817:1-2024. Он смещает акцент с "проработки вообще" на конкретные потребности.
Примерный алгоритм:
🛑 прописали цель 🔍 поняли, какая информация нужна на конкретном этапе🔍 закрепили в виде требования.
Это трудоемкий, но исчерпывающий подход, который избавит исполнителя от лишней работы, а заказчика от ненужной информации.
На перспективу:
Отрасли еще предстоит переосмыслить подход к уровням проработки в пользу гибкости и реальным потребностям, исключая "информационный шум" в моделях и определяя требования к способу представления геометрии (mesh, brep, solid и т.д.).
Поразмыслить на тему:
🔴 Даешь LOD 3000!
🔴 Что такое LOIN (УИП)
🔴 Кто, как и когда определяет LOIN (УИП)
🔴 SOI - альтернатива LOD (раз, два)
👥 @IFC_ru
👥 @IFC_club
Проблема LOD
Продолжая тему целей в ТЗ разберем ключевую проблему LOD. На представленных примерах видно, что эта концепция часто работает не как рабочий инструмент, а как источник хаоса.
🔹Ни в одном ТЗ, что приходилось видеть, LOD не применяется единообразно. Каждый изобретает свой подход, что сводит пользу концепции к минимуму.
🔹Кроме того, не указываются способы представления геометрии. Нужен ли элемент как Brep или solid? Или достаточно mesh? (А если меsh, то какая плотность сетки полигонов?).
🔹Связано это с тем, что использование LOD без привязки к конкретным целям, без четкого понимания, кому и зачем это нужно, вызывает больше путаницы, чем порядка.
Если цель - "получение ПД" (без конкретики), то проработка элементов с большой вероятностью не будет соответствовать тому, что вы ожидаете. А если главная задача в ТЗ - "повышение эффективности проектирования", то это не задача, а получаемый эффект. Поэтому важно исходить из требований к конкретной информации, которую необходимо получить.
Это поняли разработчики ISO 19650 и ввели понятие Level of Information Need и выпустили ISO 7817:1-2024. Он смещает акцент с "проработки вообще" на конкретные потребности.
Примерный алгоритм:
🛑 прописали цель 🔍 поняли, какая информация нужна на конкретном этапе🔍 закрепили в виде требования.
Это трудоемкий, но исчерпывающий подход, который избавит исполнителя от лишней работы, а заказчика от ненужной информации.
На перспективу:
Отрасли еще предстоит переосмыслить подход к уровням проработки в пользу гибкости и реальным потребностям, исключая "информационный шум" в моделях и определяя требования к способу представления геометрии (mesh, brep, solid и т.д.).
Поразмыслить на тему:
🔴 Даешь LOD 3000!
🔴 Что такое LOIN (УИП)
🔴 Кто, как и когда определяет LOIN (УИП)
🔴 SOI - альтернатива LOD (раз, два)
👥 @IFC_ru
👥 @IFC_club