PostGIS'te büyük nokta bulutu lazer verileri - Depolama ve İşleme

Acaba, çok sayıda lazer taranmış nokta bulutu verisini PostGIS'de nasıl saklayacağımızı ve bunları akılda tutmanın zamanı geldiğini merak ediyorum. Biliyorum, PointPostGIS'de bir geometri nesnesi var . Ancak bildiğim kadarıyla, her bir noktayı yeni bir tupelde kaydeder, bu da birkaç milyon veya daha fazla depolanmışsa, herhangi bir noktayı aramayı çok yavaş bir süreç haline getirebilir.

HSR Uygulamalı Bilimler Üniversitesi Rapperswill'den bu konuyu tartışan bir makale buldum. : Bu tür veri depolamak için üç yol göstermektedir Whole data in one tupel, Each point in one tupelya da Splitting Data into Blocksher bir bloğun uzanan tutma, bilgi-tablolar başvurulur. Üçüncü yol saklanan noktaları bulmak için en yararlı gibi göründüğü için, merak ediyorum zaten kimse onunla bazı deneyimler yapmış mı?

Makale burada bulunabilir: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Son olarak, PostgeSQL'deki nokta bulutu davranışlarıyla ilgilenen github üzerine bir projeye rastladım. Ne yazık ki net etrafında bu konuda fazla bilgi yok. Yani burada aynı soru: Birisi onunla daha önce bazı deneyimler yaşadı mı? Bu amaçlar için kullanılabilir mi?

Proje burada bulunabilir: https://github.com/pramsey/pointcloud

Varsa diğer önerileri, fikirleri veya deneyimleri duymaktan memnuniyet duyarım. Ama itiraf etmeliyim ki, ticari olmayan çözümler tercih ediliyor.

postgis postgresql lidar

— knutella
kaynak

Devasa ne demek istediğiniz hakkında kaba bir fikir verebilir misiniz ve nokta bulutundan ne tür bilgilere ihtiyacınız var? Yani sadece XYZ ve yoğunluk, örneğin engellenen MultipointZM'de veya muhtemelen her bir ayrı nokta ölçümü için benzersiz değerler elde etmek için Point gerektiren diğer özellik verilerinde saklanabilir mi?

— Torsti

lidarı sınıflandırma ile 10x10 metre çoklu noktalarda depolarım. Biz sadece zemin Z değerlerini kullanmak

— simplexio

@AndreSilva Amaç, verilerden yol yüzey profilleri oluşturmaktır. Şimdilik noktaları DEM ızgaralarına dönüştürdük ve PostGIS'i raster blokları olarak saklamak için kullandık ve sonunda profil oluşturmak için SAGA'yı kullandık. Test amacıyla çalışır, ancak aynı zamanda db içe aktarmadan önce verileri rasterleştirerek doğruluk kaybı anlamına gelir. Ayrıca, verilen profil çizgileri tarafından kesilen ızgara hücrelerinin ihracatı PostGIS'te çok yavaş gidiyor (ST_Union sayesinde). Benzer görevler için araçlar önerebilirseniz iyi olur.

— knutella

@til_b: Bu tam olarak bahsettiğim şeydi ... İyi bul :)

— knutella

Aynı soruyu kendime sordum ve çalışan bir prototip elde etmek için bazı parçaları bir araya getirdim. Şimdiye kadar harika çalışıyor , milyonlarca ila yüz milyonlarca noktadan her biri yaklaşık 20 öznitelikle ölçeklenebilirlik sorunu yok. Bu kadar puanla, bir alanın içindeki noktaları bulmak birkaç yüz milis alır . Zaman damgasına göre filtrelemek yaklaşık aynı zaman alır (benim için kesin edinme zamanı). Genel olarak, "LiDAR Veri Yönetimi Boru Hattı; Mekansal Veritabanı Nüfusundan Web Uygulaması Görselleştirmesine" kadar olan veri aynı veya daha iyidir Veri DB'ye sıkıştırılır (yaklaşık 1: 2

Yanıtlar:

Sorunuzda çok şey var. Kısa cevap evet, büyük nokta bulutu verilerini PostGIS'de saklamak ve işlemek için kullanmak tamamen mümkündür. Bunu yapan tam bir sistem kurduk.

Bu video, sayılarıyla biraz güncel değil, ancak arka uçta işlemek için Python aracılığıyla erişilebilen postgis'te mobil / karasal ve hava verileri TB'leri ve 3D ön izleme ve verilerin indirilmesini sağlayan bir web ön ucu vardı. https://vimeo.com/39053196

Verileri PostGIS'te nasıl depolamayı seçtiğinize ve nasıl erişeceğinize bağlı. Hava verileri için iyi bir çözüm, verileri bir şekilde ızgaralamak ve verimlilik için çoklu noktaları kullanmak olabilir. Bununla birlikte, nokta yoğunluğunun metre kare başına 500-30000 + nokta arasında olabileceği mobil veya karasal verilerle çalışıyorsanız, bu yaklaşım işe yaramaz. Ardından, donanımınıza ve beklediğiniz eşzamanlı kullanıcı sayısına bakılır. Bununla ilgili ayrıntılar bazı makalelerimizde bulunabilir http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
kaynak

Merhaba, çok detaylı bilgi için teşekkürler. Makalelerinizde sunulan ides / testler gerçekten yararlı görünüyor! Hepsini görmek biraz zaman alacak ama ilk okumada gördüğüm gibi, zaten tüm geçici çözümleri sağlıyorlar. Eklediğiniz için çok teşekkürler! Ayrıca video ve tarayıcı tabanlı pc-görüntüleyici oldukça ilginç ve çok iyi ve düzgün çalışıyor gibi görünüyor! Maalesef ellerimi kısa süreli diğer şeylere verdim. Kısaca pc-data ile devam etmeyi umuyorum.

— knutella

Glimpse projesinin burada gerçekten harika bir demosu var: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(Cevap benim ve diğerlerinin yukarıdaki yorumlarına dayanmaktadır; gerçekten test etmedim)

Noktaları MultiPointZM olarak saklayın. En iyi ızgara boyutu muhtemelen erişim kalıplarına bağlı olacaktır ve bu konuda bazı testler yapmanız gerekir. Uzamsal bir dizine sahip düzenli bir ızgara sorguları oldukça hızlı hale getirmelidir. 3B erişim önemliyse, MultiPointZM 2B düzlem ızgara yerine 3B blok tabanlı (1) olabilir, o zaman (PostGIS> = 2.0 varsa) hızlı 3B sorgular için &&& kullanabilirsiniz.

Izgara desenini ayrı bir tabloda da saklayabilirsiniz; bu, örneğin verileri güncellerken ve MultiPointZM bloklarının düzenlemelerden sonra sınırlarında kaldığını doğrularken faydalı olabilir.

Zaman damgalarını veya diğer verileri yalnızca bir kerede bir blok için saklamak mümkün olabilir, ancak çok fazla kategori ve / veya nitelik yoksa, her bir bloğun niteliğe göre ayrılmasıyla bazı ikili / kategori verileri saklanabilir.

Verileri ayrı bir PointZM olarak saklamak zorunda kalırsanız, ızgara tablosundaki + B-Tree dizinindeki yabancı bir anahtar, uzamsal olsa bile, yalnızca belirli noktaların (muhtemelen) doğrudan tabloyu sorgulamaktan çok daha hızlı yüklenmesini sağlar. indeks.

(1) Z-değerleri aralığı küçükse (sonuçta bu bir yoldur), bu muhtemelen bir anlam ifade etmez.

— Torsti
kaynak

Bence 'özet' daha önce tartışılan önerilerin bir sonucu olarak oldukça iyi sonuç verir. Söylediğiniz gibi, bu tür verileri yüklemenin 'doğru' yolu, ihtiyaçlar ve önerilen çözümler içinde anlaşılmalıdır. Bu kadar çok fikir sayesinde imkansız olmayacaktı. Bu konuda daha fazla çalışmam için bana ilham verdi. Çok teşekkürler!

— knutella