В архитектурно-строительной сфере с появлением BIM-технологий всё больше приходится работать с данными, анализировать их и визуализировать для наглядности и понимания. При проектировании зданий и сооружений большое внимание уделяется качеству проектных решений, в том числе предотвращению коллизий на строительной площадке. Работая с BIM-моделями мы можем более качественно и заблаговременно получать информацию о потенциальных коллизиях. Полученные данные необходимо анализировать и принимать в работу, а также визуализировать для донесения более широкому кругу людей, в том числе. Эта статья является более расширенной версией поста с Dzen про формирование динамической матрицы коллизий. Судя по обратной связи, многим не хватило более подробного раскрытия процесса импорта и преобразования отчёта .xml в Power BI и дальнейшая работа с данными. В этой статье я постараюсь дать более подробный гайд, но также освещу весь процесс начиная с формирования поисковых наборов (Search Sets) в Autodesk Navisworks для более целостной картины. В конце должны получить примерно такой результат: Прежде чем проверять BIM-модель на коллизии в Navisworks, необходимо создать поисковые наборы для более гибкой и качественной проверки. Поскольку, практически любой BIM-специалист знает, как создавать их, то заострять внимание на этом не буду и в качестве примера возьму уже преднастроенные поисковые наборы.  Для получения и подготовки отчёта переходим на вкладку Clash Detective и формируем проверки на коллизии. В зависимости от требований и регламентов структура будет отличаться. Нажимаем Запустить проверку и видим некоторую информацию о конфликтах(коллизиях) и их количестве:   После чего переходим на вкладку Отчёт Перед экспортом отчёта, для упрощения в данном случае, в поле Содержимое оставим выборку только у пункта Сводка и в поле Включить эти статусы: уберём всю выборку, нам нужна только общая информация о количестве коллизий в каждой проверки, без детализации. Тип отчёта — Все тесты (совм.); Формат отчёта — XML. В итоге получаем файл отчёта в .xml формате. Для более подробной информации по работе с коллизиями, необходимо выбирать дополнительные пункты, в зависимости от нужных вам данных, которые планируете использовать в работе. Повторюсь, в примере они все убраны для упрощения, так как версионность проверок учитываться не будет. XML (от англ. eXtensible Markup Language) — «расширяемый язык разметки» и прежде чем идти дальше, необходимо изучить/освежить знания о структуре XML. Вкратце об XML можно почитать тут. Некоторая выдержка из источника:   XML документ должен содержать корневой элемент. Этот элемент является «родительским» для всех других элементов. Все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов. Все элементы могут иметь подэлементы (дочерние элементы): Похожую структуру мы увидим, если откроем наш отчёт в VS Code, например, или Notepad++  Для дальнейшей работы с импортом и преобразованием в Power BI, нам достаточно обобщённо понимать эту иерархию и вложенность. По сути, в элементах <clashtest>...</clashtest> записаны наши проверки из Navisworks: На иллюстрации выше показана одна из проверок и как она выглядит в XML-структуре с минимальным набором информации. Поисковые наборы, о которых шла речь вначале, формируются по такому же принципу. Соответственно, создав поисковый набор, вы можете экспортировать его в .xml и посмотреть, как там устроено под капотом, что-то поменять и импортировать обратно в Navisworks, получив новый набор. Отсюда вытекает, что формировать поисковые наборы (особенно когда их много) можно и вне интерфейса Navisworks, но это уже тема для отдельной статьи.   Устанавливаем Microsoft Power BI, если его нет и запускаем программу. Далее устанавливаем связь с источником данных или другими словами — импортируем, ранее подготовленный .xml отчёт. Нажимаем на текст Получение данных из другого источника и в выпадающем окне выбираем нужный формат — XML Пройдёт процесс подключения к источнику и появится окно с таблицей, состоящей из нескольких ячеек. Тут нам уже важно понимать содержимое, так как судя по обратной связи из первоначальной статьи, вопрос многих BIM-специалистов был в преобразовании таблицы и дальнейшая работа с ней. Если мы вернёмся к .xml отчёту в текстовом редакторе и сопоставим с появившейся таблицей, то заметим в ней верхнеуровневый элемент <batchtest></batchtest> и некоторые атрибуты units="m" filename="" filepath="" из корневого элемента <exchange></exchange>. Начальный фрагмент XML-структуры из .xml отчёта: Мы понимаем, что нужная информация лежит внутри иерархии и её необходимо достать/преобразовать в нужный нам табличный вид для последующей работы с данными. Жмём Преобразовать данные. Попадаем в Редактор 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. На выходе должны сформироваться два дополнительных столбца с постфиксом (группы) в конце таблицы. Именно этими значениями в дальнейшем мы будем оперировать и выводить на финальный отчёт в матрице коллизий.  Переходим обратно в основную рабочую область — Представление отчёта. Вкратце опишу основные области, с которыми будем работать: Представление отчёта или рабочая область с отчётами, уже знакомая вкладка  — именно тут мы размещаем и компонуем наши графики, чарты и т.д., вследствие чего формируем финальные Дашборды. Визуализация — поле с преднастройками по типам отчётов, последующая визуальная постобработка и всё, что с этим связано. Данные — поле с источниками данных, в нашем случае преобразованная таблица с вложенным списком, по сути, столбцы. Теперь из области Данные выбираем нужные пункты (столбцы с данными) и уже видим, как формируется простая таблица. Далее выбираем визуальный элемент — Матрица в поле Визуализации и получаем уже нужную нам матрицу коллизий. Сразу можно ещё скорректировать ячейку в верхнем левом углу. Сейчас там Attribute:name.1 (группы), а мы хотим написать "Раздел", для обозначения аббревиатур в заголовках вертикальной и горизонтальной линиях. Для этого в поле Визуализации под заголовком Строки наводим на плашку с именем Attribute:name.1 (группы) в область стрелки и в выпадающем списке выбираем "Переименовать для этого визуального элемента". Осталось только поработать над визуальной частью и дополнительно, как вариант, добавить отчёт с установленными допусками проверок на коллизии между разделами. Выделяем отчёт и переходим на появившуюся вкладку Форматирование визуального элемента в поле Визуализации. Детально рассматривать все настройки не буду, покажу несколько, в качестве примера, чтобы получить более менее приемлемый вид.  Предустановка стилей — минимальный, Можно добавить горизонтальные и вертикальные сетки и вывести их в белый цвет, Отцентрируем заголовки и значения в ячейках, Добавим цвет фона у ячеек со значениями, Немного увеличить строки в размере Выведем Подсказки во второй вкладке Общий, чтобы при наведении на любую ячейку всплывало окошко с дополнительной информацией, Добавить название таблицы с сопутствующими настройками, И так далее по вкусу. Отдельно следует выделить плашку под названием Элементы ячейки, где имеет смысл применить параметры к цвету фона и закрашивать ячейки в зависимости от их значений. Тем самым визуально, сразу становится понятен проблемный и критический пул коллизий по количеству, касательно разделов. Разобраться с настройками визуальной части не составит большого труда, учитывая, что инструментарий тут достаточно топорный и не так много возможностей настройки стандартных визуальных элементов. Либо я не знаю многих нюансов и приёмов в прикладном плане, что больше походит на правду. По итогу, после ряда манипуляций получаем подобный результат: Таблицы интерактивные и мы можем взаимодействовать со строками, столбцами и ячейками, фокусируясь на них. В финальной таблице добавил недостающую проверку ЭОМ - ЭОМ и убрал нули, через применение параметров к цвету шрифта в области Элементы ячейки, вкладки Визуальный элемент. Для обновления данных перезаписываем отчёт .xml из Navisworks и обновляем в Power BI: вкладка Главная — поле Запросы — кнопка Обновить, таблица скорректируется, если были изменения. В статье рассмотрен относительно упрощённый пример формирования матрицы коллизий в Power BI. Если подключить дополнительные атрибуты при экспорте отчёта в XML из Navisworks, то можно пойти дальше и вести временную шкалу проверок, получать метрики по исправленным и добавленным коллизиям и т.д., но основная цель статьи — более подробно раскрыть процесс импорта и преобразования XML данных в Power BI для BIM-специалистов. Если остались вопросы — пишите. Спасибо за внимание.  BIM / VDC Management