Введение

В архитектурно-строительной сфере с появлением 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-структуре с минимальным набором информации.

Формирование отчёта в 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 для последующего преобразования и подготовки данных.

Теперь предстоит добраться до нужной информации и для этого мы проваливаемся внутри структуры до нужного уровня вложенности. В столбце batchtest нажимаем на значение ячейки Table, потом clashtests — Table и т.д., как в примере:

Слева в поле Запросы видны наши источники данных, а в поле Параметры запроса вкладки Свойства и Применённые шаги, где мы можем откатиться назад (на один или несколько уровней) либо всё сбросить и вернуться к первоначальному виду.

В новом табличном представлении уже видим столбцы Attribute:name и Attribute:tolerance со знакомыми названиями проверок на коллизии и их допусками, которые изначально формировали в Navisworks.

Далее, нужно извлечь из столбца summary вложенные значения с количеством найденных коллизий, а именно Attribute:total и изменить тип значений на Целое число, нажав ПКМ по заголовку столбца:

Также следует разбить столбец Attribute:name на два, тем самым разделив левую часть проверки (А) и правую (B). Для последующего представления в матрице:

Для этого, в интерфейсе Редактора Power Query есть функция Разделить столбец. Поскольку в наименованиях моих проверок есть понятный разделить в виде символа - дефис, то делить, я буду по нему (у вас может быть другой).

Выделяем нужный столбец, кликнув на заголовок: Разделить столбец — по разделителю — выбираем знак в выпадающем списке, либо Пользовательский:

В результате получится два столбца — левая(А) и правая(B) проверки. Attribute:name.1 и Attribute:name.2

Жмём Закрыть и применить в верхнем левом углу и переходим к последнему шагу в части подготовки данных — группировка всех проверок в соответствующие разделы проектной документации: АР, КР, ОВ и т.д., чтобы выводить общие показатели по ним.

После того, как вышли из режима редактирования запроса, попадаем в главную рабочую область Power BI, которую рассмотрим чуть позже. В левой части окна есть три иконки: Представление отчёта (область в который мы находимся сейчас), Представление таблицы и Представление модели.

Выбираем Представление таблицы и видим знакомую нам табличку, но уже без верхнеуровневых столбцов, в которые можно провалиться.

Выделяем первый столбец с заголовком Attribute:name.1 и группируем его, нажимая на инструмент Группы данных — Создать группы данных. Тут немного ручной работы, но довольно быстрой и понятной. В окне Группы в левой колонке находятся Несгруппированные значения, которые необходимо сгруппировать, переместив в правую колонку и задав логическое имя группе. Алгоритм действий прост — выделяем через SHIFT все нужные наборы (идентифицируя по префиксу в данном случае АИ.., АР.., ВК.., и т.д.) жмём Группировать, два раза кликаем ЛКМ на сформированный заголовок группы, чтобы сразу переименовать в понятный раздел.

Соответственно, таким же образом поступаем и со вторым столбцом Attribute:name.2. На выходе должны сформироваться два дополнительных столбца с постфиксом (группы) в конце таблицы.

Именно этими значениями в дальнейшем мы будем оперировать и выводить на финальный отчёт в матрице коллизий.

Переходим обратно в основную рабочую область — Представление отчёта.

Рабочая область Power BI и подготовка отчёта

Вкратце опишу основные области, с которыми будем работать:

1. Представление отчёта или рабочая область с отчётами, уже знакомая вкладка — именно тут мы размещаем и компонуем наши графики, чарты и т.д., вследствие чего формируем финальные Дашборды.

2. Визуализация — поле с преднастройками по типам отчётов, последующая визуальная постобработка и всё, что с этим связано.

3. Данные — поле с источниками данных, в нашем случае преобразованная таблица с вложенным списком, по сути, столбцы.

Теперь из области Данные выбираем нужные пункты (столбцы с данными) и уже видим, как формируется простая таблица. Далее выбираем визуальный элемент — Матрица в поле Визуализации и получаем уже нужную нам матрицу коллизий.

Сразу можно ещё скорректировать ячейку в верхнем левом углу. Сейчас там Attribute:name.1 (группы), а мы хотим написать "Раздел", для обозначения аббревиатур в заголовках вертикальной и горизонтальной линиях. Для этого в поле Визуализации под заголовком Строки наводим на плашку с именем Attribute:name.1 (группы) в область стрелки и в выпадающем списке выбираем "Переименовать для этого визуального элемента".

Осталось только поработать над визуальной частью и дополнительно, как вариант, добавить отчёт с установленными допусками проверок на коллизии между разделами.

Финальная настройка визуально-интерактивной матрицы коллизий

Выделяем отчёт и переходим на появившуюся вкладку Форматирование визуального элемента в поле Визуализации.

Детально рассматривать все настройки не буду, покажу несколько, в качестве примера, чтобы получить более менее приемлемый вид.

• Предустановка стилей — минимальный,

• Можно добавить горизонтальные и вертикальные сетки и вывести их в белый цвет,

• Отцентрируем заголовки и значения в ячейках,

• Добавим цвет фона у ячеек со значениями,

• Немного увеличить строки в размере

• Выведем Подсказки во второй вкладке Общий, чтобы при наведении на любую ячейку всплывало окошко с дополнительной информацией,

• Добавить название таблицы с сопутствующими настройками,

• И так далее по вкусу.

Отдельно следует выделить плашку под названием Элементы ячейки, где имеет смысл применить параметры к цвету фона и закрашивать ячейки в зависимости от их значений. Тем самым визуально, сразу становится понятен проблемный и критический пул коллизий по количеству, касательно разделов.

Разобраться с настройками визуальной части не составит большого труда, учитывая, что инструментарий тут достаточно топорный и не так много возможностей настройки стандартных визуальных элементов. Либо я не знаю многих нюансов и приёмов в прикладном плане, что больше походит на правду.

По итогу, после ряда манипуляций получаем подобный результат:

Таблицы интерактивные и мы можем взаимодействовать со строками, столбцами и ячейками, фокусируясь на них.

Для обновления данных перезаписываем отчёт .xml из Navisworks и обновляем в Power BI: вкладка Главная — поле Запросы — кнопка Обновить, таблица скорректируется, если были изменения.

Заключение

В статье рассмотрен относительно упрощённый пример формирования матрицы коллизий в Power BI. Если подключить дополнительные атрибуты при экспорте отчёта в XML из Navisworks, то можно пойти дальше и вести временную шкалу проверок, получать метрики по исправленным и добавленным коллизиям и т.д., но основная цель статьи — более подробно раскрыть процесс импорта и преобразования XML данных в Power BI для BIM-специалистов. Если остались вопросы — пишите.

Спасибо за внимание.