Величезні хмарні лазерні дані в PostGIS - зберігання та обробка їх

Цікаво, як можна зберігати величезний набір даних про хмарно скановану точку хмари в PostGIS, враховуючи часовий аспект їх обробки. Я знаю, Pointв PostGIS існує об’єкт геометрії . Але наскільки я знаю, це зберігає кожну точку в новому тюпелі, що може зробити пошук будь-якої точки дуже повільним процесом, якщо їх збережено кілька мільйонів і більше.

Я знайшов документ із HSR Universtiy of Applied Sciences Rapperswill, який обговорював цю тему. Він пропонує три способи зберігання таких даних: 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 і використовувати їх для обробки. Ми створили таку повну систему, яка це робить.

Це відео трохи застаріло з його номерами, але у нас були ТБ мобільних / наземних та повітряних даних у постгігах, доступних через python для обробки в задньому кінці та з веб-переднім кінцем, що дозволяє переглядати та завантажувати дані в 3D. https://vimeo.com/39053196

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

(Відповідь ґрунтується на моїх та інших коментарях вище; насправді її не перевіряли)

Зберігайте точки як MultiPointZM. Найкращий розмір сітки, ймовірно, залежатиме від шаблонів доступу, і вам потрібно зробити тестування на це. Звичайна сітка з просторовим індексом повинна робити запити досить швидкими. Якщо доступ до 3D важливий, то MultiPointZM може бути на основі 3D-блоку (1) замість двовимірної плоскої сітки, тоді (якщо у вас PostGIS> = 2.0) ви зможете використовувати &&& для швидких 3D-запитів.

Ви також можете зберігати шаблон сітки в окремій таблиці, що може бути корисним, наприклад, при оновленні даних та підтвердженні того, що блоки MultiPointZM залишаються в межах своєї межі після редагувань тощо.

Збереження часових міток або інших даних буде можливим лише для блоку за один раз, але деякі двійкові / категорії даних можуть бути збережені, розставляючи кожен блок за атрибутом, якщо не занадто багато категорій та / або атрибутів.

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

(1) Якщо діапазон значень Z невеликий (зрештою, це дорога), це, мабуть, не має сенсу.