Введение
В архитектурно-строительной сфере с появлением BIM-технологий всё больше приходится работать с данными, анализировать их и визуализировать для наглядности и понимания. При проектировании зданий и сооружений большое внимание уделяется качеству проектных решений, в том числе предотвращению коллизий на строительной площадке. Работая с BIM-моделями мы можем более качественно и заблаговременно получать информацию о потенциальных коллизиях. Полученные данные необходимо анализировать и принимать в работу, а также визуализировать для донесения более широкому кругу людей, в том числе.
Эта статья является более расширенной версией поста с Dzen про формирование динамической матрицы коллизий. Судя по обратной связи, многим не хватило более подробного раскрытия процесса импорта и преобразования отчёта .xml в Power BI и дальнейшая работа с данными. В этой статье я постараюсь дать более подробный гайд, но также освещу весь процесс начиная с формирования поисковых наборов (Search Sets) в Autodesk Navisworks для более целостной картины.
В конце должны получить примерно такой результат:
Подготовка проверок на коллизии в Autodesk Navisworks
Создание поисковых наборов
Прежде чем проверять BIM-модель на коллизии в Navisworks, необходимо создать поисковые наборы для более гибкой и качественной проверки. Поскольку, практически любой BIM-специалист знает, как создавать их, то заострять внимание на этом не буду и в качестве примера возьму уже преднастроенные поисковые наборы.
Формирование отчёта проверок
Для получения и подготовки отчёта переходим на вкладку Clash Detective и формируем проверки на коллизии. В зависимости от требований и регламентов структура будет отличаться.
Нажимаем Запустить проверку и видим некоторую информацию о конфликтах(коллизиях) и их количестве:
После чего переходим на вкладку Отчёт
Экспорт отчёта в XML
Перед экспортом отчёта, для упрощения в данном случае, в поле Содержимое оставим выборку только у пункта Сводка и в поле Включить эти статусы: уберём всю выборку, нам нужна только общая информация о количестве коллизий в каждой проверки, без детализации. Тип отчёта — Все тесты (совм.); Формат отчёта — XML.
В итоге получаем файл отчёта в .xml формате.
Примечание:
Для более подробной информации по работе с коллизиями, необходимо выбирать дополнительные пункты, в зависимости от нужных вам данных, которые планируете использовать в работе. Повторюсь, в примере они все убраны для упрощения, так как версионность проверок учитываться не будет.
Структура XML отчёта
XML (от англ. eXtensible Markup Language) — «расширяемый язык разметки» и прежде чем идти дальше, необходимо изучить/освежить знания о структуре XML. Вкратце об XML можно почитать тут. Некоторая выдержка из источника:
XML документ должен содержать корневой элемент. Этот элемент является «родительским» для всех других элементов.
Все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов.
Все элементы могут иметь подэлементы (дочерние элементы):
<корневой>
<потомок>
<подпотомок>.....</подпотомок>
</потомок>
</корневой>Похожую структуру мы увидим, если откроем наш отчёт в VS Code, например, или Notepad++
Для дальнейшей работы с импортом и преобразованием в Power BI, нам достаточно обобщённо понимать эту иерархию и вложенность. По сути, в элементах <clashtest>...</clashtest> записаны наши проверки из Navisworks:
На иллюстрации выше показана одна из проверок и как она выглядит в XML-структуре с минимальным набором информации.
Примечание:
Поисковые наборы, о которых шла речь вначале, формируются по такому же принципу. Соответственно, создав поисковый набор, вы можете экспортировать его в .xml и посмотреть, как там устроено под капотом, что-то поменять и импортировать обратно в Navisworks, получив новый набор. Отсюда вытекает, что формировать поисковые наборы (особенно когда их много) можно и вне интерфейса Navisworks, но это уже тема для отдельной статьи.
Формирование отчёта в Power BI
Связь с источником данных — импорт отчёта XML
Устанавливаем Microsoft Power BI, если его нет и запускаем программу. Далее устанавливаем связь с источником данных или другими словами — импортируем, ранее подготовленный .xml отчёт.
Нажимаем на текст Получение данных из другого источника и в выпадающем окне выбираем нужный формат — XML
Пройдёт процесс подключения к источнику и появится окно с таблицей, состоящей из нескольких ячеек. Тут нам уже важно понимать содержимое, так как судя по обратной связи из первоначальной статьи, вопрос многих BIM-специалистов был в преобразовании таблицы и дальнейшая работа с ней.
Если мы вернёмся к .xml отчёту в текстовом редакторе и сопоставим с появившейся таблицей, то заметим в ней верхнеуровневый элемент <batchtest></batchtest> и некоторые атрибуты units="m" filename="" filepath="" из корневого элемента <exchange></exchange>.
Начальный фрагмент XML-структуры из .xml отчёта:
<?xml version="1.0" encoding="UTF-8" ?>
<exchange xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" units="m" filename="" filepath="">
<batchtest name="Report" internal_name="Report" units="m">
<clashtests>
<clashtest name="АИ1 Стены-АИ1 Стены" test_type="hard" status="ok" tolerance="0.010" merge_composites="0">
<linkage mode="none"/>
<left>
...
Мы понимаем, что нужная информация лежит внутри иерархии и её необходимо достать/преобразовать в нужный нам табличный вид для последующей работы с данными. Жмём Преобразовать данные.
Настройка представления таблицы. Редактор Power Query
Попадаем в Редактор Power Query для последующего преобразования и подготовки данных.
Примечание:
Power Query — это модуль преобразования данных и подсистемы подготовки данных. Power Query поставляется с графическим интерфейсом для получения данных из источников и редактора Power Query для применения преобразований.
Теперь предстоит добраться до нужной информации и для этого мы проваливаемся внутри структуры до нужного уровня вложенности. В столбце batchtest нажимаем на значение ячейки Table, потом clashtests — Table и т.д., как в примере:
Слева в поле Запросы видны наши источники данных, а в поле Параметры запроса вкладки Свойства и Применённые шаги, где мы можем откатиться назад (на один или несколько уровней) либо всё сбросить и вернуться к первоначальному виду.
В новом табличном представлении уже видим столбцы Attribute:name и Attribute:tolerance со знакомыми названиями проверок на коллизии и их допусками, которые изначально формировали в Navisworks.
Далее, нужно извлечь из столбца summary вложенные значения с количеством найденных коллизий, а именно Attribute:total и изменить тип значений на Целое число, нажав ПКМ по заголовку столбца:
Примечание:
В дальнейшем, если вы планируете поставить на рельсы процесс сбора проверок на коллизии, отслеживать изменения и статусы и выводить эти отчёты в Power BI, то процедура преобразования будет немного другая, потому нужны будут и другие статусы — new, active, reviewed и т.д.
Также следует разбить столбец Attribute:name на два, тем самым разделив левую часть проверки (А) и правую (B). Для последующего представления в матрице:
Для этого, в интерфейсе Редактора Power Query есть функция Разделить столбец. Поскольку в наименованиях моих проверок есть понятный разделить в виде символа - дефис, то делить, я буду по нему (у вас может быть другой).
Выделяем нужный столбец, кликнув на заголовок: Разделить столбец — по разделителю — выбираем знак в выпадающем списке, либо Пользовательский:
В результате получится два столбца — левая(А) и правая(B) проверки. Attribute:name.1 и Attribute:name.2
Жмём Закрыть и применить в верхнем левом углу и переходим к последнему шагу в части подготовки данных — группировка всех проверок в соответствующие разделы проектной документации: АР, КР, ОВ и т.д., чтобы выводить общие показатели по ним.
Примечание:
Если вы формируете проверки в Navisworks по принципу "модель на модель" или "раздел на раздел", а не разделяете их более подробно на наборы как в примере статьи, то следующий шаг по группировкам для вас может быть не актуален.
После того, как вышли из режима редактирования запроса, попадаем в главную рабочую область Power BI, которую рассмотрим чуть позже. В левой части окна есть три иконки: Представление отчёта (область в который мы находимся сейчас), Представление таблицы и Представление модели.
Выбираем Представление таблицы и видим знакомую нам табличку, но уже без верхнеуровневых столбцов, в которые можно провалиться.
Выделяем первый столбец с заголовком Attribute:name.1 и группируем его, нажимая на инструмент Группы данных — Создать группы данных. Тут немного ручной работы, но довольно быстрой и понятной. В окне Группы в левой колонке находятся Несгруппированные значения, которые необходимо сгруппировать, переместив в правую колонку и задав логическое имя группе. Алгоритм действий прост — выделяем через SHIFT все нужные наборы (идентифицируя по префиксу в данном случае АИ.., АР.., ВК.., и т.д.) жмём Группировать, два раза кликаем ЛКМ на сформированный заголовок группы, чтобы сразу переименовать в понятный раздел.
Соответственно, таким же образом поступаем и со вторым столбцом Attribute:name.2. На выходе должны сформироваться два дополнительных столбца с постфиксом (группы) в конце таблицы.
Именно этими значениями в дальнейшем мы будем оперировать и выводить на финальный отчёт в матрице коллизий.
Переходим обратно в основную рабочую область — Представление отчёта.
Рабочая область Power BI и подготовка отчёта
Вкратце опишу основные области, с которыми будем работать:
Представление отчёта или рабочая область с отчётами, уже знакомая вкладка — именно тут мы размещаем и компонуем наши графики, чарты и т.д., вследствие чего формируем финальные Дашборды.
Визуализация — поле с преднастройками по типам отчётов, последующая визуальная постобработка и всё, что с этим связано.
Данные — поле с источниками данных, в нашем случае преобразованная таблица с вложенным списком, по сути, столбцы.
Теперь из области Данные выбираем нужные пункты (столбцы с данными) и уже видим, как формируется простая таблица. Далее выбираем визуальный элемент — Матрица в поле Визуализации и получаем уже нужную нам матрицу коллизий.
Сразу можно ещё скорректировать ячейку в верхнем левом углу. Сейчас там Attribute:name.1 (группы), а мы хотим написать "Раздел", для обозначения аббревиатур в заголовках вертикальной и горизонтальной линиях. Для этого в поле Визуализации под заголовком Строки наводим на плашку с именем Attribute:name.1 (группы) в область стрелки и в выпадающем списке выбираем "Переименовать для этого визуального элемента".
Осталось только поработать над визуальной частью и дополнительно, как вариант, добавить отчёт с установленными допусками проверок на коллизии между разделами.
Финальная настройка визуально-интерактивной матрицы коллизий
Выделяем отчёт и переходим на появившуюся вкладку Форматирование визуального элемента в поле Визуализации.
Детально рассматривать все настройки не буду, покажу несколько, в качестве примера, чтобы получить более менее приемлемый вид.
Предустановка стилей — минимальный,
Можно добавить горизонтальные и вертикальные сетки и вывести их в белый цвет,
Отцентрируем заголовки и значения в ячейках,
Добавим цвет фона у ячеек со значениями,
Немного увеличить строки в размере
Выведем Подсказки во второй вкладке Общий, чтобы при наведении на любую ячейку всплывало окошко с дополнительной информацией,
Добавить название таблицы с сопутствующими настройками,
И так далее по вкусу.
Отдельно следует выделить плашку под названием Элементы ячейки, где имеет смысл применить параметры к цвету фона и закрашивать ячейки в зависимости от их значений. Тем самым визуально, сразу становится понятен проблемный и критический пул коллизий по количеству, касательно разделов.
Разобраться с настройками визуальной части не составит большого труда, учитывая, что инструментарий тут достаточно топорный и не так много возможностей настройки стандартных визуальных элементов. Либо я не знаю многих нюансов и приёмов в прикладном плане, что больше походит на правду.
По итогу, после ряда манипуляций получаем подобный результат:
Таблицы интерактивные и мы можем взаимодействовать со строками, столбцами и ячейками, фокусируясь на них.
Примечание:
В финальной таблице добавил недостающую проверку ЭОМ - ЭОМ и убрал нули, через применение параметров к цвету шрифта в области Элементы ячейки, вкладки Визуальный элемент.
Для обновления данных перезаписываем отчёт .xml из Navisworks и обновляем в Power BI: вкладка Главная — поле Запросы — кнопка Обновить, таблица скорректируется, если были изменения.
Заключение
В статье рассмотрен относительно упрощённый пример формирования матрицы коллизий в Power BI. Если подключить дополнительные атрибуты при экспорте отчёта в XML из Navisworks, то можно пойти дальше и вести временную шкалу проверок, получать метрики по исправленным и добавленным коллизиям и т.д., но основная цель статьи — более подробно раскрыть процесс импорта и преобразования XML данных в Power BI для BIM-специалистов. Если остались вопросы — пишите.
Спасибо за внимание.
