Введение: данная статья продолжает серию статей по постобработке и использованию облаков точек для задач инфраструктуры и генплана; в первой части мы касались вопроса растеризации облаков точек, в этой - начнем говорить о методике формировании поверхностей по облакам точек с акцентом на возможности последующего использования этих поверхностей в проектной работе (баланс числа точек и точности поверхности).
Для того, чтобы не углубляться в бесконечность, эту статью ограничим введением в проблему создания поверхностей по облакам точек и рассмотрим возможности фильтрации точек земли по облакам точек для возможности работы с полученными данными впоследствии в рамках проектных решений.
При этом ограничимся случаем создания поверхности по точкам облака без учета линейных элементов (внимание которым посвятим в третьей части - поскольку там будут применяться принципиально иные методы обработки).
1. О практической необходимости
Сами по себе съемки местности при помощи лазерного сканирования - не новая фича, они проводились ещё с конца 1990х (правда, и техника стоила сильно дорого). С развитием техники (снижением цен на приборы, на ПО, с увеличением производительности) стали появляться новые задачи и сферы применения лазерного сканирования - в том числе, съемка площадных территорий (в контексте задачи инженерно-геодезических изысканий на местности). При этом несмотря на то, что фотограмметрия - есть совершенно другая технология производства и получения данных, "пост-результат" её также обычно представляет собой облака точек - поэтому мы будем рассматривать эти 2 процесса получения данных как единый.
Задача моделирования поверхностей по облакам точек, в общем случае - также "избитая" вещь. Наибольшая известность отдельных практических кейсов - это измерение объемов земляных работ на промышленных площадках, карьерах посредством построения поверхности по насыпи и формированию объема материала. Здесь поверхность выступает как средство получения данных об объеме и далее, фактически, как сущность не используется.
Другой частный случай применение технологии лазерного сканирования - ландшафтный дизайн при съемке дачно-садовых участков. Пример подобных данных проиллюстрирован здесь.
Здесь поверхность уже зачастую выступает как 3D-модель ситуации (данные о существующем рельефе, существующих объектах/коммуникациях). Данные, которые получают при помощи таковой модели - отметки высот, горизонтали с подписями отметок высот - фактически "DWG-подоснову" (исходники - саму 3D-модель поверхности, как правило, не отдают, и после завершения проекта она больше не используется). В большинстве своём, подобные кейсы связаны с работой по файлу только ради получения ограниченных данных.
Третья сторона - это получение 3D-модели поверхности для использования в рамках проектных решений генплана для крупных проектов. Здесь "кейс" частично коррелируется с примером выше - только с тем условием, что поверхность должна быть редактируемой (грань между точностью и комфортностью работы). Именно этому мы и посвятим нашу статью.
Примечание: будем отталкиваться от следующих условий:
- Изыскания нам проводят специалисты, уравнивая координаты до используемых МСК в рамках проекта, а также уравнивая высоты до нормальных высот в Балтийской системе высот (или иной используемой);
- Исходники у нас - это облака точек в одном из общепринятых форматов (las/e57/txt[xyz/xyzrgb/pts]);
- Облака точек не классифицированы.
2. Немного про объемы работ и производительность
Рост технической производительности лазерных сканов и факт выполнения работ по изысканиям подрядными организациями (не заинтересованных, зачастую, в возможности дальнейшей работы с данными [если это не прописано в Договоре]) приводит к ситуации, когда использовать полученные данные сразу для формирования поверхностей, не представляется возможным. То есть данные должны пройти процедуру фильтрации\выборки перед дальнейшим использованием для проектных работ.
Давайте сперва грубо прикинем формулу расчета требуемых аппаратных ресурсов для открытия облака точек из N-точек.
Положим, что облака точек - это 3 координаты X,Y,Z и цветовой код RGB. Если предположить, что координаты хранятся в памяти программы как числа float (каждое весом 4 байта), а цветовой код - как тип byte/unsigned char (весом по 1 байт), то на описание 1 точек нужно 4*3+1*3 ~15 байт оперативной памяти. Тогда 1 Кб ОЗУ хватит примерно на 64 точки, а 1 Гб ОЗУ - на 67.11 млн. точек. Альтернатива - кодирование точек через единичные символы char (1 байт), тогда число, предположим "346058.8111 6646829.0058 64.106" будет занимать 28 байт (или, при сохранении сдвижки [наибольшего значения координат] - порядка 20 байт). Если рассматривать продукт CloudCompare, 1 Гб ОЗУ ~ 40 млн точек).Тогда максимальный "предел", какой "переварит" ПО при полном отображении всего облака (при наличии 64 Гб оперативной памяти) - это 64 Гб * [40...67] млн. точек = 2.5...4.3 млрд точек.
Другой вопрос, если не все точки будут участвовать в "генерации" картинки - тогда "загрузиться" могут больше данных. Совершенно другой подход у "консольных" утилит по работе с облаками точек - для которых не требуется хранить всё облако в памяти (например, набор утилит Lastools (правда, там и нет функционала по построению поверхностей).
Алгоритмически, построение поверхности по точкам (как правило, триангуляцией Делоне) - это итеративный процесс анализа всех точек облака и обход их с формированием (в памяти) самой структуры поверхности. Если сами точки воспроизводить в памяти не надо, то поверхность храниться будет (в виде упорядоченных массивов координат точек). По размерности массивов сказать не могу - но "потолок" тоже соизмерим с емкостью облаков точек в памяти компьютера.
Примечание: рекомендую эту книгу, содержащую набор разных алгоритмов генерации триангуляции Делоне от разработчиков ИндорСофт (сам я пока не добрался до реализации отдельных алгоритмов на практике, но собираюсь это сделать в будущем).
3. Варианты классификации точек земли
В первой части, в пункте 2.3 мы касались возможности применения плагина для CloudCompare под названием "CSF Filter" к облаку точек.
Глобально, можно выделить следующие программные инструменты (CloudCompare) по работе с облаками точек в части их классификации :
- плагин CSF-filter (ресурсоемкая операция);
- tool-segmantation-cross section (грубо);
- canupo - classify (не тестировал, как-нибудь постараюсь отдельно по нему написать материал);
- S.O.R filter (убирает шумы по настраиваемым параметрам, крайне ресурсоемкая операция);
Само собой, при возможности применить к облаку точек "умную классификацию", как это реализовано в коммерческом ПО типа Credo 3d scan, NanoCAD Облака точек, Global Mapper LIDAR Module и пр., следует пользоваться данной опцией - для отсеивания "ненужных" точек.
Далее применим к облаку точек обрезку облака секущей плоскостью, инструментом CSF-filter для получения набора точек для последующего формирования поверхности.
Рассмотрим некоторые варианты на примере работы с облаком точек на лесистую местность в Ленинградской области (система координат МСК 47 Зона 2), в окрестностях пос. Новое Токсово:
Примечание: если для Civil 3D у вас отсутствует набор отечественных систем координат, см. здесь как их установить
Теперь, сузив пространство для анализа, применим к нему наш CSF-Filter и получим примерно точки земли.
Для верности, повторим расчет задав большее значение числа итераций (так как значения "0.1" для параметров - минимальное из возможных, можно это делать программно - используя библиотеки плагина, но я такое пока не пробовал, сложно разобраться с С++ начинкой программы).
В целом, оставшихся точек земли теперь достаточно и можем приступать к формированию на их базе поверхности.
4. Подходы к генерации поверхностей
В большинстве ПО (или даже, в подавляющем большинстве ПО) в качестве алгоритма построения поверхности используется упомянутая раннее "триангуляция Делоне". По этой причине нет особой разницы, где поверхности будут сформированы, важнее - как они будут сформированы и можно ли их будет дополнительно редактировать.
Инструментарий CloudCompare также позволяет формировать растровое изображение с картой высот [geotiff] по облаку точек (растры, что мы получали в первой части статьи содержали лишь цветовой код). Полученный растр также может быть использован для построения поверхности.
Примечание: стоит оговориться, что фактически, поверхности, строящиеся только по облакам точек выгоднее строить именно "сетчатыми", то есть базовой фигурой делать не треугольник (триангуляция"), а четырехугольник - сетку (либо его заместитель - 2 треугольника вдоль одной из диагоналей ячейки сетки как делает InfraWorks).
Построение поверхности триангуляцией по облаку точек не рекомендуется ввиду сложности редактирования этой структуры и желательно применять только для целей расчета объема, тогда как сетчатые поверхности более редактируемы.
Отдельно, можно формировать изолинии/горизонтали опять же средствами модуля rasterize (про который мы не раз говорили, в том числе в этой статье).
Таким образом, сформируем некоторый подытог способов построения поверхностей:
- генерация tin-поверхности (получение готового mesh'а, который передаем в конечное ПО):
- формирование растра с матрицей высот (geotif/DEM файл), по которому строим сетчатую поверхность
- формируем горизонтали по растру/DEM-файлу
Мы рассмотрим варианты получения сетчатой (растр) и tin-поверхности в CloudCompare, а также средствами Autodesk InfraWorks. Обе построенные поверхности будем редактировать в AutoCAD Civil 3D.
4.1 Построение tin-поверхности в CloudCompare
Сохранить ее можно только в DXF-файл (для возможности использовать в Civil 3D), поэтому при большом числе ребер этот процесс затянется (экспорт, импорт), да и само представление поверхности сразу в TIN-формате, как мы сказали, сам по себе не является гибким. Поэтому оставим этот способ и перейдем к следующему - формирование DEM-файла поверхности.
4.2 Формирование DEM-файла в CloudCompare
Запомним красивую картинку и повторим процедуру генерации растра с другими параметрами (введя заполнение пустых ячеек методом интерполяции).
Также стоит обратить внимание на позицию "cell height" - у меня установлено average (среднее значение) - если в ячейку (пиксель растра) попадает несколько точек, то в качестве отметки матрицы высот берется среднее значение. Следует не допускать выставления minimum/maximum - так как при отсутствии фильтрации и удаления шумов могут получаться экстремальные значения.
4.3 Формируем рельеф средствами InfraWorks
Autodesk InfraWorks, к слову, сам строит фактически, сетчатые поверхности с регулярным шагом по облаку точек (при этом при протяженном объекте он сам берет большой шаг между точками ячеек - делая результат крайне условным, поэтому на больших зонах его использовать не рекомендуется).
Для построения поверхности в него нужно загрузить облако точек. У него есть свои алгоритмы классификации, но они работают так себе, поэтому ему лучше подавать уже отфильтрованное облако точек (точки земли).
Используя скрипт составления RCP-проекта с помощью Decap.exe (по материалам данной статьи) запускаем процедуру генерации проекта RCP для последующей загрузки его в среду InfraWorks:
Обратим внимание на "рваные" края поверхности - где не имелось по краю точек, InfraWorks не смог соединить ребрами - это нам придется делать в Civil 3D
4.4* Преобразование растра в поверхность
В силу того, что Civil 3D не умеет читать все типы файлов geotiff, нам придется открыть данный растр в InfraWorks и пересохранить как поверхность для Civil 3D
Обратим внимание на края снимка - это следствие недостатка данных для формирования рельефа в CC. Оставим как есть и экспортируем в качестве поверхности (потом ограничим поверхности от данных ошибочных вершин).
5. Упрощение поверхностей и дальнейшая обработка для последующего использования
5.1 Загрузка данных
Теперь переходим в Civil 3D и загружаем туда поверхности:
К слову, поверхность, построенная средствами IW после данной операции теперь выглядит нормально (с заполненными пустыми ячейками).
5.2 Предварительное сравнение поверхностей между собой
Видны огромные цифры невязки! Посмотрим на карту высот для сравниваемых поверхностей - чтобы понять места возникновения невязок:
Можно заметить большое количество фиолетовых пятен (невязки от 10 см до 187 см) среди лесного-травяного массива (что говорит о недостаточной классификации данных). Там же к слову, было наибольшее число данных, в отличие от южной части скана:
Предварительный вывод: использовать поверхности, построенные с сеткой 0.5*0.5м можно только при условии качественной предварительной классификации точек земли. В противном случае - невязка с реальными данными будет огромной!
Теперь сравним поверхность, построенную средствами IW и сетчатыми:
Из анализа видим, что результаты разнятся +/- на 20 м3 в значениях выемки и насыпи, что тоже неприемлемый результат. Если в сравнении двух сетчатых поверхностей взаимная невязка была ~ 21 м3, то в сравнении обеих с IW - невязка уже составляет более 260 м3.
5.3 Операции упрощения поверхности
Приняв, что сетчатая поверхность с шагом 0.5x0.5 м нас устраивает, пойдем по пути её упрощения. Для этого будем отталкиваться от её текущего состояния, и производить операции сравнения новых версий поверхности со старым (скопировав поверхность в новое Определение поверхности и производя изменения с ней независимо от начальной версии).
Теперь сформируем поверхность сравнения - для контроля уместности изменений (для соблюдения точности)
Примерно в таком ключе формируются поверхности до конечной стадии - когда число точек будет приемлемо и картинка поверхности будет примерно соответствовать исходной tin/grid-поверхности по облаку точек.
6. Выводы
Фактически, как бы мы ни пытались решить задачу упрощения поверхности для лесного массива (демонстрируемого выше) - всё будет упираться в классификацию точек земли для формирования исходной поверхности, поскольку при применении операций получаются огромные невязки с исходными данными (и даже при разных настройках обработки).
В целом, настоящая статья иллюстрирует методику обработки облаков точек (наземного/воздушного лазерного сканирования, фотограмметрии) в open-source software - CloudCompare и дальнейшую обработку в AutoCAD Civil 3D (альтернативную версию - в Autodesk InfraWorks).
Вещи, которые надо зафиксировать - это обязательное применение алгоритмов классификации облаков точек (иначе "объективность" данных будет нулевой), особенно в лесной/полевой зоне.
#поверхность #облака точек #cloudcompare #point cloud #классификация облака точек #сетчатые поверхности #tin поверхности
