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.
Add your support for this item by contacting us for a quote and discussion of the particular features you need.
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
Tracking collections of moving objects, querying the historical data for relationships, and maintaining alarms when objects enter/leave areas is now a very common use case. The objects might be trucks, planes, boats, people, and so on. A standard data model, support functions, and API for efficient handling of this case would be helpful.
The geodetic GEOGRAPHY operations are currently very CPU intensive, because they involved multiple trancendental math calls. Performance could be improved through caching of calculations, both at a low level (coordinates) and a high level (data structures).
For GIS data, spatial partitioning indexes (quadtree, kd-tree) have been shown to be significantly faster than more general balanced indexes (r-tree). PostGIS currently uses an r-tree index. Adding SP-GiST (a generic API for partitioned indexes) to PostgreSQL will allow much faster spatial searching in PostGIS.