ข้อมูลคลาวด์พอยต์ขนาดใหญ่ใน PostGIS - การจัดเก็บและประมวลผล

ฉันสงสัยว่าเป็นไปได้อย่างไรที่จะจัดเก็บชุดข้อมูลเมฆจุดสแกนขนาดใหญ่ใน PostGIS พร้อมเวลาในการประมวลผลในใจ ฉันรู้ว่ามีรูปทรงเรขาคณิต - วัตถุPointใน PostGIS แต่เท่าที่ฉันรู้ว่ามันช่วยให้แต่ละจุดใน tupel ใหม่ซึ่งสามารถทำการค้นหาจุดใดจุดหนึ่งเป็นกระบวนการที่ช้ามากหากเก็บไว้ไม่กี่ล้านหรือมากกว่านั้น

ฉันพบบทความจาก HSR Universtiy ของ Applied Science 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 ซึ่งดูเหมือนว่าจะจัดการกับมารยาทของ cloud point ใน PostgeSQL น่าเสียดายที่มีข้อมูลไม่มากเกี่ยวกับเรื่องนี้ในเน็ต ดังนั้นคำถามเดียวกันที่นี่: มีใครบางคนได้ทำประสบการณ์กับมันแล้ว? มันใช้งานได้สำหรับวัตถุประสงค์ดังกล่าวหรือไม่

สามารถพบโครงการได้ที่นี่: https://github.com/pramsey/pointcloud

ฉันก็ยินดีที่จะรับฟังข้อเสนอแนะความคิดหรือประสบการณ์อื่น ๆ หากมี แต่ฉันต้องยอมรับว่าไม่ใช่ทางออกเชิงพาณิชย์ที่ต้องการ

มีคำถามมากมายในคำถามของคุณ คำตอบสั้น ๆ คือใช่มันเป็นไปได้อย่างสมบูรณ์ในการจัดเก็บข้อมูลเมฆขนาดใหญ่ใน PostGIS และใช้สำหรับการประมวลผล เราได้สร้างระบบที่สมบูรณ์เช่นนี้

วิดีโอนี้มีข้อมูลล้าสมัยเล็กน้อย แต่เรามี TBs ของข้อมูลมือถือ / ภาคพื้นดินและทางอากาศในโพสต์กิสที่สามารถเข้าถึงได้ผ่านทาง Python สำหรับการประมวลผลในส่วนหลังและด้วยส่วนหน้าเว็บที่อนุญาตให้รับชม 3D https://vimeo.com/39053196

มันเป็นเรื่องเกี่ยวกับวิธีที่คุณเลือกจัดเก็บข้อมูลใน PostGIS และวิธีการเข้าถึงข้อมูลของคุณ วิธีแก้ปัญหาที่ดีสำหรับข้อมูลทางอากาศอาจเป็นการจัดตารางข้อมูลด้วยวิธีใดวิธีหนึ่งและใช้หลายจุดเพื่อประสิทธิภาพ อย่างไรก็ตามหากคุณกำลังทำงานกับข้อมูลมือถือหรือภาคพื้นดินที่ความหนาแน่นของจุดสามารถอยู่ระหว่าง 500-30000 + จุดต่อเมตรกำลังสองวิธีนี้ไม่ทำงาน ถ้าอย่างนั้นก็มาดูที่ฮาร์ดแวร์ของคุณและจำนวนผู้ใช้ที่เกิดขึ้นพร้อมกันที่คุณคาดหวัง รายละเอียดเกี่ยวกับเรื่องนี้สามารถพบได้ในเอกสารบางส่วนของเรา http://www.mendeley.com/profiles/conor-mc-elhinney/

(คำตอบนั้นขึ้นอยู่กับความคิดเห็นของฉันและของผู้อื่นด้านบน แต่ยังไม่ได้ทดสอบจริง ๆ )

เก็บคะแนนเป็น MultiPointZM ขนาดกริดที่ดีที่สุดอาจขึ้นอยู่กับรูปแบบการเข้าถึงและคุณจำเป็นต้องทำการทดสอบบางอย่างกับสิ่งนี้ กริดปกติที่มีดัชนีปริภูมิควรทำการสืบค้นอย่างรวดเร็ว หากการเข้าถึง 3d เป็นสิ่งสำคัญ MultiPointZM สามารถใช้บล็อก 3 มิติ (1) แทนที่จะเป็นกริด 2D ได้ดังนั้น (ถ้าคุณมี PostGIS> = 2.0) คุณจะสามารถใช้ &&& เพื่อการสืบค้น 3D ได้อย่างรวดเร็ว

คุณสามารถจัดเก็บรูปแบบกริดในตารางแยกซึ่งอาจเป็นประโยชน์เช่นเมื่ออัปเดตข้อมูลและตรวจสอบว่าบล็อก MultiPointZM อยู่ภายในขอบเขตหลังจากแก้ไขแล้วเป็นต้น

การจัดเก็บเวลาประทับหรือข้อมูลอื่น ๆ จะทำได้เพียงครั้งละหนึ่งบล็อก แต่ข้อมูลไบนารี / หมวดหมู่บางส่วนสามารถจัดเก็บได้โดยแยกการบล็อกแต่ละรายการโดยแอตทริบิวต์หากมีหมวดหมู่และ / หรือแอตทริบิวต์ไม่มากเกินไป

หากคุณต้องเก็บข้อมูลเป็น PointZM แยกต่างหากจากนั้นคีย์ต่างประเทศในตารางกริด + ดัชนี B-Tree จะทำให้โหลดเฉพาะจุดที่ระบุ (อาจ) เร็วกว่าการป้อนตารางโดยตรงแม้จะเป็นพื้นที่ ดัชนี.

(1) หากช่วงของค่า Z มีขนาดเล็ก (เป็นถนนหลังจากนั้นทั้งหมด) สิ่งนี้อาจไม่สมเหตุสมผล