Огромные лазерные данные облака точек в PostGIS - их хранение и обработка

Интересно, как можно хранить огромные наборы данных облака отсканированных лазером точек в PostGIS, учитывая время обработки? Я знаю, что существует объект геометрии Pointв PostGIS. Но, насколько я знаю, это сохраняет каждую точку в новом наборе, что может сделать поиск любой определенной точки очень медленным процессом, если хранится несколько миллионов или более из них.

Я нашел статью из Университета прикладных наук Рапперса, посвященную этой теме. Он предлагает три способа хранения таких данных: Whole data in one tupel, Each point in one tupelили Splitting Data into Blocksкоторые ссылаются инфо-таблицами, держа расширяет каждый блок. Поскольку третий способ кажется наиболее полезным для определения местоположения сохраненных точек, мне интересно, кто-нибудь уже имел опыт работы с ним?

Документ можно найти здесь: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

И последнее, но не менее важное: я наткнулся на проект на github, который, похоже, имеет дело с манерами облаков точек в PostgeSQL. К сожалению, не так много информации об этом в сети. Итак, тот же вопрос: кто-то уже имел опыт? Это можно использовать для таких целей?

Проект можно найти здесь: https://github.com/pramsey/pointcloud

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

postgis postgresql lidar

— knutella
источник

Не могли бы вы дать приблизительное представление о том, что вы подразумеваете под огромным, и какая информация из облака точек вам нужна? Т.е. только XYZ и интенсивность, которые, например, могут храниться в заблокированном MultipointZM, или также другие атрибутные данные, которые, вероятно, требуют, чтобы Point получал уникальные значения для каждого отдельного измерения точки?

— Торсти

Я храню лидар в многоточечных 10х10 м по классификации. Мы используем только

— базовые

@AndreSilva Целью является создание профилей поверхности дороги из данных. На данный момент мы преобразовали точки в сетки DEM и использовали PostGIS для хранения их в виде растровых блоков, а SAGA для создания в итоге профилей из них. Он работает в целях тестирования, но это также означает потерю точности из-за растеризации данных перед импортом базы данных. Также экспорт ячеек сетки, вырезанных по заданным линиям профиля, идет очень медленно в PostGIS (благодаря ST_Union). Было бы неплохо, если бы вы могли порекомендовать инструменты для подобных задач.

— Кнутелла

@til_b: Ну, это именно то, о чем я говорил ... Хорошая находка :)

— knutella

Я задал себе тот же вопрос и собрал несколько частей, чтобы получить работающий прототип. Пока он работает отлично , без проблем масштабируемости от нескольких миллионов до сотен миллионов точек с около 20 атрибутами в каждой. С таким количеством точек нахождение точек внутри области занимает несколько сотен миллис . Фильтрация по метке времени занимает примерно то же время (точное время получения для меня). В целом, производительность такая же или лучше, чем в «Линии управления данными LiDAR; от заполнения пространственной базы данных до визуализации веб-приложений». Данные сжимаются в БД (примерно 1: 2

Ответы:

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

Это видео немного устарело с его номерами, но у нас были ТБ мобильных / наземных и аэрофотоснимков в postgis, доступные через python для обработки в бэкэнде и с веб-интерфейсом, позволяющим просматривать и загружать данные в 3D. https://vimeo.com/39053196

Это действительно сводится к тому, как вы решили хранить данные в PostGIS и как вы собираетесь получать к ним доступ. Хорошее решение для аэрофотоснимков вполне может заключаться в том, чтобы каким-то образом распределять данные по сетке и использовать многоточечные для эффективности. Однако, если вы работаете с мобильными или наземными данными, где плотность точек может составлять 500-30000 + точек на квадратный метр, такой подход не работает. Затем все сводится к анализу вашего оборудования и ожидаемого количества одновременно работающих пользователей. Подробности об этом можно найти в некоторых наших статьях http://www.mendeley.com/profiles/conor-mc-elhinney/

— Конор
источник

Привет, спасибо за очень подробную информацию. Идентификаторы / тесты, предлагаемые в ваших статьях, кажутся действительно полезными! Мне понадобится некоторое время, чтобы все это увидеть, но, как я увидел при первом прочтении, они уже предоставляют целые обходные пути. Большое спасибо за добавление! Кроме того, видео и ваш браузер на ПК выглядят довольно интересно и, кажется, работают очень хорошо и гладко! К сожалению, у меня возникли проблемы с другими вещами. Я надеюсь продолжить с ПК-данными в ближайшее время, хотя.

— Кнутелла

Проект Glimpse имеет действительно здорово демо здесь: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(Ответ основан на моих и других комментариях выше; на самом деле не проверял)

Сохраните точки как MultiPointZM. Наилучший размер сетки, вероятно, будет зависеть от шаблонов доступа, и вам нужно провести некоторое тестирование по этому вопросу. Обычная сетка с пространственным индексом должна выполнять запросы довольно быстро. Если важен трехмерный доступ, тогда MultiPointZM может основываться на трехмерном блоке (1) вместо двумерной плоской сетки, тогда (если у вас PostGIS> = 2.0), вы сможете использовать &&& для быстрых трехмерных запросов.

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

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

Если вам в конечном итоге придется хранить данные как отдельный PointZM, то внешний ключ в таблице сетки + индекс B-Tree сделает загрузку только определенных точек (возможно) намного быстрее, чем просто запрос таблицы напрямую, даже с пространственным показатель.

(1) Если диапазон значений Z мал (в конце концов, это дорога), это, вероятно, не имеет смысла.

— Торсти
источник

Я думаю, что ваше «резюме» очень хорошо отражается в заключении предыдущих обсужденных предложений. Как вы сказали, «правильный» способ загрузки таких данных должен быть найден в соответствии с потребностями и предлагаемыми решениями. Оказалось, не быть невозможным благодаря так много идей. Это вдохновило меня на дальнейшую работу над этим вопросом. Большое спасибо!

— Кнутелла