Dữ liệu laser đám mây điểm lớn trong PostGIS - Lưu trữ và xử lý nó

Tôi tự hỏi, làm thế nào có thể lưu trữ các tập hợp dữ liệu đám mây điểm quét laser khổng lồ trong PostGIS, với khía cạnh thời gian để xử lý nó trong tâm trí. Tôi biết, tồn tại một đối tượng hình học Pointtrong PostGIS. Nhưng theo như tôi biết, nó lưu từng điểm trong một tupel mới, điều này có thể khiến cho việc tìm kiếm bất kỳ điểm nào đó trở thành một quá trình rất chậm, nếu một vài triệu hoặc nhiều hơn trong số chúng được lưu trữ.

Tôi tìm thấy một bài báo từ HSR Universtiy của Khoa học ứng dụng Rapperswill, thảo luận về chủ đề này. Nó gợi ý ba cách để lưu trữ dữ liệu như: Whole data in one tupel, Each point in one tupelhoặc Splitting Data into Blocksđược tham chiếu bởi info-bảng, giữ kéo dài của mỗi khối. Vì cách thứ ba có vẻ hữu ích nhất để định vị các điểm được lưu trữ, tôi tự hỏi liệu có ai đã thực hiện một số kinh nghiệm với nó chưa?

Bài viết có thể được tìm thấy ở đây: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Cuối cùng nhưng không kém phần quan trọng, tôi tình cờ tìm thấy một dự án trên github, dường như để đối phó với cách cư xử đám mây điểm trong PostgeQuery. Thật không may, không có nhiều thông tin về nó trên mạng. Vì vậy, cùng một câu hỏi ở đây: Có ai đó đã thực hiện một số kinh nghiệm với nó? Có thể sử dụng cho các mục đích như vậy?

Dự án có thể được tìm thấy ở đây: https://github.com/pramsey/pointcloud

Tôi cũng sẽ rất vui khi nghe về những gợi ý, ý tưởng hoặc kinh nghiệm khác, nếu có. Nhưng tôi phải thừa nhận rằng các giải pháp phi thương mại được ưa thích hơn.

postgis postgresql lidar

— knutella
nguồn

Bạn có thể đưa ra một ý tưởng sơ bộ về ý nghĩa to lớn của bạn và bạn cần loại thông tin nào từ đám mây điểm? Tức là chỉ XYZ và cường độ, ví dụ có thể được lưu trữ trong MultipointZM bị chặn hoặc dữ liệu thuộc tính khác có thể yêu cầu Điểm để nhận các giá trị duy nhất cho mỗi phép đo điểm riêng biệt?

— Torsti

tôi lưu trữ flipar trong đa điểm 10 x 10 mét theo phân loại. Chúng tôi chỉ sử dụng các giá trị Z mặt đất

— Simplexio

@AndreSilva Mục đích là để tạo hồ sơ bề mặt đường ra khỏi dữ liệu. Hiện tại, chúng tôi đã chuyển đổi các điểm thành lưới DEM và sử dụng PostGIS để lưu trữ chúng dưới dạng rasterblocks và SAGA để tạo cuối cùng các cấu hình từ nó. Nó chạy cho mục đích thử nghiệm, nhưng nó cũng có nghĩa là mất độ chính xác thông qua việc quét dữ liệu trước khi nhập db. Ngoài ra, việc xuất các ô lưới, được cắt bởi các dòng hồ sơ đã cho diễn ra rất chậm trong PostGIS (nhờ ST_Union). Sẽ rất tuyệt nếu bạn có thể giới thiệu các công cụ cho các nhiệm vụ tương tự.

— knutella

@til_b: Chà, đây chính xác là những gì tôi đã nói về ... Tìm tốt :)

— knutella

Tôi đã tự hỏi mình câu hỏi tương tự, và ghép một số mảnh lại với nhau để có được một nguyên mẫu hoạt động. Cho đến nay, nó hoạt động rất tốt , không có vấn đề về khả năng mở rộng từ vài triệu đến hàng trăm triệu điểm với khoảng 20 thuộc tính mỗi điểm. Với nhiều điểm này, việc tìm kiếm các điểm trong một khu vực mất vài trăm mili . Mất khoảng thời gian tương tự để lọc theo dấu thời gian (thời gian thu chính xác đối với tôi). Nhìn chung, sự hoàn hảo giống hoặc tốt hơn trong "Đường ống quản lý dữ liệu LiDAR; từ dân số cơ sở dữ liệu không gian đến trực quan hóa ứng dụng web" Dữ liệu được nén vào DB (khoảng 1: 2

Câu trả lời:

Có rất nhiều trong câu hỏi của bạn. Câu trả lời ngắn gọn là có, hoàn toàn có thể lưu trữ dữ liệu đám mây điểm khổng lồ trong PostGIS và sử dụng nó để xử lý. Chúng tôi đã xây dựng một hệ thống đầy đủ như vậy làm điều này.

Video này hơi lỗi thời với số lượng nhưng chúng tôi đã có TB dữ liệu di động / mặt đất và trên không trong postgis có thể truy cập thông qua python để xử lý ở mặt sau và với giao diện người dùng web cho phép xem và tải xuống dữ liệu 3D. https://vimeo.com/39053196

Nó thực sự phụ thuộc vào cách bạn chọn lưu trữ dữ liệu trong PostGIS và cách bạn sẽ truy cập dữ liệu đó. Một giải pháp tốt cho dữ liệu trên không cũng có thể là chia lưới dữ liệu theo một cách nào đó và sử dụng đa điểm cho hiệu quả. Tuy nhiên, nếu bạn đang làm việc với dữ liệu di động hoặc mặt đất nơi mật độ điểm có thể nằm trong khoảng 500-30000 + điểm trên một mét thì phương pháp này không hiệu quả. Sau đó, xem xét phần cứng của bạn và số lượng người dùng đồng thời bạn mong đợi. Chi tiết về điều này có thể được tìm thấy trong một số bài báo của chúng tôi http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
nguồn

Xin chào, cảm ơn rất nhiều thông tin chi tiết. Các ides / bài kiểm tra được cung cấp trong bài báo của bạn có vẻ thực sự hữu ích! Tôi sẽ mất một thời gian để xem hết nhưng như tôi đã thấy trong lần đọc đầu tiên, họ đã cung cấp toàn bộ cách giải quyết. Cảm ơn rất nhiều cho việc thêm! Ngoài ra video và trình xem máy tính dựa trên trình duyệt của bạn khá thú vị và dường như hoạt động rất tốt và mượt mà! Thật không may, tôi đã bị bó tay trong thời gian ngắn. Tôi hy vọng sẽ tiếp tục với pc-data trong thời gian ngắn.

— knutella

Dự án Glimpse có một bản demo thực sự thú vị ở đây: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(Câu trả lời dựa trên ý kiến của tôi và những người khác ở trên; chưa thực sự kiểm tra nó)

Lưu trữ các điểm dưới dạng MultiPointZM. Kích thước lưới tốt nhất có thể sẽ phụ thuộc vào các mẫu truy cập và bạn cần thực hiện một số thử nghiệm về điều này. Một lưới thông thường với chỉ mục không gian sẽ thực hiện các truy vấn khá nhanh. Nếu truy cập 3d là quan trọng thì MultiPointZM có thể dựa trên khối 3D (1) thay vì lưới mặt phẳng 2D, thì (nếu bạn có PostGIS> = 2.0), bạn có thể sử dụng &&& cho các truy vấn 3D nhanh.

Bạn cũng có thể lưu trữ mẫu lưới trong một bảng riêng biệt, điều này có thể hữu ích, ví dụ như khi cập nhật dữ liệu và xác thực rằng các khối MultiPointZM nằm trong giới hạn của chúng sau khi chỉnh sửa, v.v.

Lưu trữ dấu thời gian hoặc dữ liệu khác chỉ có thể cho một khối tại một thời điểm, nhưng một số dữ liệu nhị phân / danh mục có thể được lưu trữ bằng cách phân tách từng khối theo thuộc tính nếu không có quá nhiều danh mục và / hoặc thuộc tính.

Nếu cuối cùng bạn phải lưu trữ dữ liệu dưới dạng PointZM riêng biệt, thì khóa ngoại trên bảng lưới + Chỉ mục B-Tree sẽ khiến việc tải chỉ các điểm cụ thể (có thể) nhanh hơn rất nhiều so với việc chỉ quét trực tiếp bảng, ngay cả với không gian mục lục.

(1) Nếu phạm vi của các giá trị Z là nhỏ (rốt cuộc thì đó là một con đường), điều này có lẽ không có ý nghĩa gì.

— Torsti
nguồn

Tôi nghĩ rằng 'tóm tắt' của bạn khá tốt khi kết luận về các đề xuất được thảo luận trước đây. Như bạn đã nói, cách 'đúng' để tải dữ liệu đó phải được tìm ra trong các nhu cầu và giải pháp đề xuất. Hóa ra, không phải là không thể nhờ rất nhiều ý tưởng. Nó đã cho tôi rất nhiều cảm hứng cho công việc tiếp theo của tôi về vấn đề này. Cảm ơn rất nhiều!

— knutella