Higher Dimensional Index Summary
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.
The implementation of higher-dimensional indexes will take some care, to provide users with the flexibility necessary to use them to maximum advantage. For example, the mere presence of a higher dimension on the data does not imply the index should be of higher dimension – the user may wish to only index in X/Y.
The CREATE INDEX statement will likely remain the same, with the default indexing being X/Y indexing. The higher dimensional indexes will be brought into play with different "ops" specified in the GIST portion of the call. For example:
CREATE INDEX the_index ON the_table USING GIST (the_geometry GIST_GEOMETRY_OPS3D())
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
The PostGIS spatial index currently splits pages based on longest edge. This results in trees that have sub-optimal spatial clustering in the branches, which in turn makes for sub-optimal clustering. A packed R-Tree would provide the highest performance clustering.
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).
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.