Point Cloud Summary
“Point clouds” are huge collections of multi-dimensional points automatically collected using LIDAR or side-scan sonar systems.
Point clouds can be directly stored in PostGIS as point tables, but doing so is highly inefficient, in terms of disk storage and index size. Also, LIDAR data include more than 4 dimensions for each point – an X, Y and Z are present, but so are variables like return type, signal strength, time, and so on.
A proper storage system for LIDAR data would respect the multi-dimensionality of the data, optimize performance for data extraction and storage size, and provide the kind of granular random access users expect from database systems.
The solution to the problem is a "POINTPATCH" type, a data type that will store multiple multi-dimensional points in a single database object.
The POINTPATCH type will
- be no larger than a database page, to enhance access speed
- be spatially indexed in three dimensions, to allow fast access in the most common dimensions
- include a data loading tool to bring LAS files into the database
- include a data loading tool to bring simple point-based shape files into the database
- include support functions for working with the data in the database
- PP_Filter(POINTPATCH, ARRAY[DIMENSIONS]) to extract certain dimensions from the patch
- PP_Union(ARRAY[POINTPATCH]) to turn a collection of patches into a single patch
- PP_Split(POINTPATCH) to split a large point patch into a smaller set that fit inside the page size
- include a cast to GEOMETRY, to allow display of point patches with standard GIS applications
Funding
This roadmap item is currently unfunded.
Get a quote now!
Get a quote or read more about core development to add your support to a road-map item.
Other Roadmap Items
Support for ST_Union(), ST_Difference(), and true/false predicate tests calculated natively on the sphere for the GEOGRAPHY type introduced in PostGIS 1.5.
The LRS functions in PostGIS are a mismatched combination of functions that operate on measures and functions that use length as a proxy to measure. A re-work to formalize the LRS handling is needed.
Geometry matching function in PostGIS are currently biased toward exact matches. However, spatial data is often “logically equivalent but physically disjoint” – the machine representations are close but not exact even though the geometries represent the same features.