Higher Dimensionality Cleanup
The support for dimensions higher than X/Y is uneven as currently implemented. Most operations support clean handling of the Z dimension. A reasonable number of important functions do not support handling of the M dimension.
For example, the ST_MakeLine function does not build output lines that include the higher dimensions on the input points. The ST_Intersection function does not retain M-values that are on the inputs.
In general, any function that uses the GEOS library for functions will lose M-values, as they are not carried into the library.
This work item will catalogue all functions and their handling of higher dimensions, will improve the GEOS library to carry M-values through operations, and will improve operations to not lose higher dimension values where it is possible to retain them through operations.
For some operations that create new geometries (ST_Buffer(), ST_ConvexHull()) retention of extra dimensions is problematic, but in general most functions should be able to handle higher dimensions cleanly.
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
Indexed Nearest Neighbor Searches
Currently nearest-neighbor searching is carried out with ad hoc tricks that expand a search radius until a candidate set is generated, then finding the closest value in the candidate set. A directly indexed approach would be optimally fast.
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.
The PostGIS spatial index currently works exclusively in the X/Y plane. For data such as fleet tracking the “Z” or “time” dimension can serve as a useful query restriction. Higher dimensional indexes are needed.