Форматы облаков точек: чем отличаются E57, LAS, LAZ, PTS, PTX и RCP

Заказчик просит передать облако точек. В одном проекте ему отправляют E57, в другом — LAS, в третьем — RCP. На экране результат может выглядеть практически одинаково: те же стены, оборудование, рельеф или дорожное полотно, собранные из миллионов трехмерных точек.

Но внутри эти файлы устроены совершенно по-разному.

Один может содержать только координаты XYZ. Другой — цвет, интенсивность отраженного сигнала, классификацию и номера отражений лазерного импульса. Третий способен сохранить отдельные позиции сканирования, положение сканера и панорамные фотографии. А четвертый вообще представляет собой не само облако, а проект, связанный с несколькими файлами данных.

Поэтому формат облака точек — это не просто расширение после имени файла. От него зависит, какую часть исходной информации удастся сохранить, передать в другое программное обеспечение и использовать спустя несколько лет после съемки.

Разберемся, чем отличаются E57, LAS, LAZ, PTS, PTX, RCP и другие распространенные форматы, где каждый из них применяется и почему универсального «лучшего формата облака точек» не существует.

Облако точек — это гораздо больше, чем XYZ

В простейшем случае каждая точка описывается тремя координатами:

X, Y, Z.

Этого достаточно, чтобы восстановить геометрию объекта. Но современные лазерные сканеры и лидары получают намного больше информации.

В зависимости от оборудования и технологии съемки с точкой или набором данных могут быть связаны:

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

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

Поэтому вопрос «E57 или LAS?» не совсем корректен сам по себе.

Правильнее сначала спросить:

что именно мы хотим сохранить и для какой дальнейшей работы нужны данные?

Четыре уровня представления облака точек

Чтобы не запутаться в десятках расширений, полезно разделить их на несколько условных групп.

Простые обменные облака

XYZ, TXT, ASC, PTS

Главная задача таких форматов — передать координаты точек и ограниченный набор дополнительных параметров.

Они просты и совместимы с огромным количеством программ, но плохо подходят для хранения полного контекста современной лазерной съемки.

Геопространственные LiDAR-данные

LAS, LAZ, COPC

Здесь вместе с координатами можно хранить богатый набор характеристик LiDAR-точек: интенсивность, номера отражений, классификацию, время измерения, географическую привязку и дополнительные атрибуты.

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

Структурированные данные Reality Capture

E57, PTX

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

Нативные данные и проекты программных экосистем

FLS, LGS/LGSx, TZF, RXP, RDB/RDBX, ZFS, RCP/RCS и другие

Здесь хранятся данные в форме, максимально удобной для конкретного оборудования или программного обеспечения.

Именно поэтому файл облака точек, исходный скан и полный проект лазерного сканирования — не одно и то же.

E57: универсальный язык Reality Capture

Если требуется передать данные наземного лазерного сканирования между программами разных производителей, E57 сегодня является одним из наиболее удобных и распространенных вариантов.

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

Но главное преимущество E57 раскрывается при работе со структурированными данными.

Structured и unstructured E57

Представим, что промышленный объект отснят с 40 позиций.

Можно объединить все зарегистрированные сканы в одно большое облако и передать его как единый массив точек.

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

Во втором случае речь идет о structured E57.

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

Unstructured E57 обычно представляет собой уже объединенное облако, где геометрия объекта сохраняется, но часть информации о происхождении отдельных точек может отсутствовать.

Именно поэтому фраза:

«Передайте облако в E57»

не всегда полностью описывает требования к результату.

Если данные будут использоваться для дальнейшей регистрации, просмотра виртуальных станций, работы с панорамами или других операций, зависящих от структуры скана, лучше заранее уточнить, нужен ли structured E57.

Есть и еще один нюанс: возможности самого стандарта и возможности конкретной программы — не одно и то же.

Одна программа может экспортировать E57 со структурой отдельных сканов, другая — только объединенное облако. Третья может считать часть атрибутов, но проигнорировать остальные.

Поэтому при сложном обмене всегда важно проверять не просто:

«Поддерживает ли программа E57?»

а:

«Что именно она умеет читать и записывать внутри E57?»

LAS: формат для геопространственного LiDAR

LAS появился в другой технологической среде и решает другую задачу.

Если E57 особенно хорошо подходит для Reality Capture и наземного сканирования, то LAS ориентирован прежде всего на геопространственные LiDAR-данные.

Вместе с координатами он может хранить:

• интенсивность;

• номер отражения;

• количество отражений импульса;

• классификацию;

• время измерения;

• RGB;

• сведения о канале сканирования;

• систему координат;

• дополнительные поля.

Поэтому LAS естественно чувствует себя в проектах воздушного и мобильного лазерного сканирования, картографии, GIS, съемки рельефа, лесного хозяйства и других задачах, где важна характеристика каждой отдельной LiDAR-точки.

Отсюда хорошо видно принципиальное отличие от E57.

Допустим, беспилотный летательный аппарат с лидаром снимает несколько квадратных километров территории. Здесь пользователю обычно не нужны «виртуальные станции сканирования». Ему значительно важнее знать координаты точек, высоту, интенсивность, класс — земля, растительность, здания — и характеристики отражений.

Для такой задачи LAS подходит прекрасно.

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

Именно здесь проходит одна из главных границ:

LAS в первую очередь описывает LiDAR-точки. E57 может дополнительно описывать контекст процесса трехмерного сканирования.

LAZ: зачем хранить огромный LAS, если его можно сжать

LAZ часто перечисляют рядом с LAS как отдельный формат, хотя по смыслу их правильнее рассматривать вместе.

LAZ — это lossless-сжатое представление LAS.

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

Практическая выгода очевидна.

Большое геопространственное облако в LAS может занимать десятки или сотни гигабайт. В LAZ тот же набор данных обычно становится значительно компактнее.

Поэтому сегодня выбор между LAS и LAZ зачастую определяется не качеством результата, а совместимостью конкретного программного обеспечения.

Если вся рабочая цепочка умеет читать LAZ напрямую, необходимость постоянно хранить и передавать огромный несжатый LAS становится значительно меньше.

PTS и PTX: почти одинаковые названия, совершенно разные данные

PTS и PTX легко перепутать. Но именно их сравнение хорошо показывает, насколько сильно формат может влиять на содержание файла.

PTS — «CSV мира облаков точек»

PTS — простой текстовый формат.

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

Его можно условно назвать CSV мира облаков точек.

PTS легко читать, относительно просто импортировать и несложно обработать собственным программным кодом. Именно поэтому он десятилетиями остается совместимым с большим количеством программ.

Но у такой простоты есть цена.

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

Если от исходного проекта осталось только PTS, восстановить из него полноценную структуру съемки уже, как правило, невозможно.

PTX — когда важна структура скана

PTX тоже является текстовым форматом, но устроен гораздо интереснее.

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

Иными словами, PTX хранит не только ответ на вопрос:

«Где находится точка?»

но и часть информации:

«Как она была получена?»

Именно поэтому PTX долгое время был важным способом обмена структурированными данными между различными системами наземного лазерного сканирования.

Недостаток очевиден: он текстовый.

Для современных сканеров, создающих сотни миллионов точек, PTX-файлы могут становиться очень большими.

Во многих сценариях structured E57 сегодня выглядит более современным вариантом, но PTX по-прежнему остается востребованным и широко поддерживаемым форматом.

Что можно потерять при конвертации

Это, пожалуй, самый важный вопрос всей темы.

Представим один и тот же зарегистрированный проект наземного лазерного сканирования.

В исходной системе существуют:

• миллионы трехмерных точек;

• десятки станций;

• положение каждого сканера;

• цвет;

• интенсивность;

• панорамные фотографии;

• структура исходных измерений;

• регистрационные трансформации;

• служебные метаданные.

Экспортируем его в structured E57 — значительную часть этого контекста потенциально можно сохранить.

Экспортируем те же данные в LAS — координаты, цвет и другие поддерживаемые атрибуты могут остаться, но станции сканирования и панорамные изображения уже не относятся к типичной структуре LAS.

Экспортируем в PTS — получим прежде всего набор точек и ограниченное количество полей.

Экспортируем в простой XYZ — останутся только те значения, для которых мы явно создали колонки.

На экране все четыре файла могут выглядеть почти одинаково.

Стена остается стеной. Труба — трубой. Перекрытие — перекрытием.

Но информационно это уже четыре разных набора данных.

Конвертация не обязательно ухудшает геометрию

Здесь важно не впадать в другую крайность.

Сам факт перехода из E57 в LAS или из FLS в E57 вовсе не означает, что координаты обязательно станут менее точными.

Чаще проблема заключается не в геометрии, а в потере контекста и атрибутов.

При конвертации могут исчезнуть или измениться:

• отдельные станции;

• положение сенсора;

• панорамы;

• классификация;

• временные данные;

• структура строк и столбцов;

• специальные характеристики отраженного сигнала;

• описание системы координат;

• дополнительные поля производителя;

• служебные метаданные.

При этом нельзя составить универсальную таблицу «E57 → LAS всегда теряет вот это».

Реальный результат зависит от двух программ:

экспортера и импортера.

Формат может поддерживать определенный атрибут, первая программа способна его записать, а вторая — просто проигнорировать.

Именно поэтому критические производственные процессы проверяют по всей цепочке:

исходное ПО → экспортный формат → целевое ПО.

RCP и RCS: когда облако попадает в Revit и AutoCAD

Для проектировщиков часто важнее совсем другой вопрос:

как подключить облако к привычной Autodesk-среде?

Здесь появляются RCS и RCP.

RCS содержит индексированные данные облака точек.

RCP — проект, который может объединять и организовывать один или несколько связанных RCS.

Это означает, что RCP и E57 нельзя напрямую считать аналогами.

E57 может выступать в роли универсального обменного файла, а RCP/RCS — в роли подготовленного рабочего представления для AutoCAD, Revit и Navisworks.

Есть и важная практическая особенность:

RCP без связанных RCS может оказаться примерно тем же, чем ярлык без файла, на который он ссылается.

Если заказчику передается Autodesk-проект, необходимо проверить полный комплект связанных данных.

E57 или RCP для BIM?

Часто правильный ответ:

и то и другое.

Например:

E57 — как нейтральное зарегистрированное облако для хранения и передачи между разными программами.

RCP/RCS — как рабочий набор, уже подготовленный для проектировщиков в Autodesk.

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

COPC: большие облака требуют другого подхода

LAZ уменьшает размер данных. Но что делать, если облако настолько велико, что даже сжатый файл содержит сотни миллионов или миллиарды точек?

Здесь появляется COPC — Cloud Optimized Point Cloud.

По сути это пространственно организованный LAZ, в котором данные устроены так, чтобы программа могла быстро считать только нужный участок облака.

Если сильно упростить:

LAS — большое облако.

LAZ — то же облако, но компактнее.

COPC — компактное облако, из которого можно эффективно получать только нужную пространственную часть.

Это особенно полезно для больших территориальных массивов, серверных систем, web-приложений и облачных платформ.

COPC не заменяет E57 — у этих форматов разные задачи. Но он хорошо показывает общее направление развития отрасли: от передачи одного огромного файла к потоковой работе с нужной частью пространственных данных.

XYZ, PLY и PCD — коротко о других форматах

XYZ, TXT, ASC

XYZ — максимально простой способ передать координаты.

Но важно понимать: часто это не единый строгий стандарт, а договоренность о структуре колонок.

Один XYZ содержит:

X Y Z

другой:

X Y Z R G B

третий:

X Y Z Intensity R G B

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

PLY

PLY активно используется там, где облако точек пересекается с 3D-геометрией, SLAM, компьютерным зрением и алгоритмической обработкой.

Он может содержать цвет, дополнительные свойства вершин и работать как с облаками, так и с полигональными моделями.

PCD

PCD — Point Cloud Data — тесно связан с Point Cloud Library.

Это уже в большей степени мир робототехники, автономной навигации, perception, SLAM и компьютерного зрения, чем классической передачи результатов геодезической съемки.

Поэтому PLY и PCD важны, но при обычном Scan-to-BIM или передаче результатов наземного лазерного сканирования заказчику выбор чаще происходит между совсем другими форматами.

Какие форматы используют производители лазерных сканеров

Помимо универсальных форматов, у крупных производителей существуют собственные форматы сканов и проектов.

И это логично: универсальный обменный файл не всегда способен сохранить абсолютно все данные оборудования и программной экосистемы.

Наиболее характерные примеры выглядят так:

Таблицу не стоит воспринимать как исчерпывающий перечень возможностей каждого производителя. Поддержка меняется между поколениями оборудования и версиями программ.

Главное здесь другое.

Например, нативный файл RIEGL может содержать специализированные характеристики измерения, важные при профессиональной обработке. После экспорта в универсальный формат сама геометрия сохранится, но часть специфической информации производителя может стать недоступной.

То же относится к проектам FARO, Leica, Trimble и других систем.

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

рабочий экспорт

и

исходные данные, которые необходимо сохранить в архиве.

Какой формат выбрать

Единственного ответа нет, но для типовых задач можно использовать следующую логику.

Но долгосрочная стратегия обычно надежнее, если не пытаться хранить проект только в одном формате.

Для важных данных разумно сохранить:

1. Исходные или нативные данные оборудования.

2. Зарегистрированный проект.

3. Открытый или широко поддерживаемый обменный формат — E57 либо LAS/LAZ в зависимости от типа съемки.

4. При необходимости — рабочее представление под конкретную программную среду, например RCP/RCS для Autodesk.

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

Что спросить у подрядчика по лазерному сканированию

Формулировки:

«Нам нужен E57»

или

«Передайте облако точек»

могут быть недостаточно точными.

Перед началом работ лучше определить:

1. Нужны исходные сканы или только зарегистрированное облако?

2. Требуется одно объединенное облако или отдельные станции?

3. Если используется E57 — нужен structured или unstructured вариант?

4. Необходимо ли сохранить RGB?

5. Нужна ли интенсивность?

6. Требуются ли панорамные изображения?

7. В какой системе координат должны находиться данные?

8. Нужна ли классификация?

9. Будет ли облако использоваться в Revit или AutoCAD?

10. Нужно ли подготовить RCP/RCS?

11. Передаются ли нативные исходные данные и проект сканирования?

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

Так какой формат все-таки лучше?

E57, LAS, LAZ, PTS, PTX и RCP существуют не потому, что индустрия не смогла договориться об одном расширении.

Они отражают разные способы работы с трехмерными данными.

E57 удобен для обмена данными Reality Capture и наземного лазерного сканирования.

LAS и LAZ отлично подходят для геопространственного LiDAR, мобильного и воздушного сканирования.

PTX сохраняет структуру отдельного скана, несмотря на большой размер текстовых файлов.

PTS и XYZ остаются простейшим способом передать точки практически в любую систему.

RCP/RCS превращают облако в удобный рабочий инструмент для экосистемы Autodesk.

COPC решает уже следующую задачу — эффективную работу с огромными пространственными массивами.

Поэтому вопрос:

«Какой формат облака точек лучший?»

стоит заменить тремя более полезными:

Что необходимо сохранить?

В каком программном обеспечении с этими данными будут работать дальше?

Какая информация может понадобиться через несколько лет?

И только после этого выбирать расширение файла.

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