Разбираем ТЗ на ЦИМ. Выпуск 6

О матрице коллизий

Тема с матрицей обширна. Но если кратко, то по сути это пространственные требования к элементам, оформленные в виде разноцветной таблицы. Построение грамотной матрицы тесно связано с проблемами, которые были подняты в предыдущих выпусках. А именно:

1. Классификация элементов позволит создать проработанную матрицу и ответит на вопрос "какие элементы проверяем?". Без четкого разделения проверки не конкретизированы и отчеты по ним плохо структурированы.

2. Деление модели на разделы нужно, чтобы целенаправленно фокусировать ресурсы ПО и проверять быстрее и точнее, а не всё подряд. ("где проверяем?").

3. Атрибутивный состав элементов нужен, чтобы ответить на вопрос "насколько это критично?". Он поможет создать продвинутый тип проверки и распределить их по степени критичности/важности. Например, в разделе КР не все элементы несущие. Для этого используем свойство "LoadBearing" (Несущий элемент). И логично, что коллизия с несущей стеной IfcWall является более критичной.

4. Привязка к целям моделирования нужна, чтобы понять, "зачем вообще мы проверяем?" Постоянно в ТЗ сталкиваемся с требованием "Проверить все коллизии с допуском 10мм". Оно не имеет цели, а только повышает трудоемкость процесса проверки. И наоборот, отсутствие связи с целями и порождает примитивную матрицу коллизий или вовсе ее отсутствие (см. скрины).

5. Требования к геометрии напрямую предопределяют результат и процесс проверки. Супердетализированные формы дольше обсчитываются в ПО.

🔍Требования по коллизиям в отрыве от этих 5 пунктов бесполезны. Это фактически не инструмент, а просто красивая табличка, где на выходе получаются тысячи неотсортированных и лишних конфликтов, разбирать которые - то еще удовольствие.

Вероятно, в перспективе исчезнет примитивное табличное оформление матриц в пользу набора смарт-правил в самом ТЗ. Но об этом как-нибудь в другой раз.

👥 @IFC_ru
👥 @IFC_club